Agreed. That's also one of the cases, where imo, a prototype would be nice.
On Thu, Dec 17, 2015 at 9:27 AM, Sebastien Goasguen <[email protected]> wrote: > Hi, > > I don’t want to be a pain but we don’t need a vote for this, it’s really a > technical discussion for which we need to reach consensus. > Votes are the last resort in ASF governance, they are used for releases > and to break ties or conflicts. > > That said :) see inline > > > On Dec 17, 2015, at 6:41 AM, anthony shaw <[email protected]> > wrote: > > > > Hi, > > > > A recent pull-request has raised the question of what to do with > > containers, specifically rkt and docker. > > > > This PR proposes docker as a compute node driver, > > https://github.com/apache/libcloud/pull/654 > > > > As you can see, the implementation doesn't line up perfectly with the > > node driver, which was really designed for VM hypervisors. There are > > some alternatives here to implement a better option. > > > > Please consider the following options and vote accordingly: > > > > 1) proceed with docker as a compute driver as stated in the #654 PR > > > > I was confused by this PR because of the use of the features which are > meant for the deploy_node step. So it looked like libcloud was used both to > instantiate a VM and start containers. This is not the case, and was > clarified in the github conversation. > > > 2) create a new driver type, ContainerNodeDriver, which INHERITS from > > NodeDriver, list_nodes would be overloaded to return ContainerNode's > > instead of Nodes. a ContainerNode (which inherits from Node) would > > share the same properties, but also have an additional property > > stating which Node it belongs to. There would be some other methods > > like pull_image, etc. That way users can use list_nodes etc. but also > > take advantage of the other functions. > > > > 3) create a new driver type, ContainerDriver and start from scratch, > > just design and implement which methods based on usage patterns in rkt > > and docker > > That’d be my preference. > > It makes sense if we think that various API are going to emerge for > containers. In libcloud philosophy, we would provide a single common API > for various container runtime. > > We would need to check the OCI to see if an API is being discussed there. > Docker has is, and it seems rkt is now providing one: > https://github.com/coreos/rkt/blob/master/api/v1alpha/api.proto > > LXD has a different one: > https://github.com/lxc/lxd/blob/master/specs/rest-api.md > > Providing a wrapper for these might be interesting and coherent with what > libcloud has provided so far. > > > > > 4) do not implement docker and/or rkt drivers at all > > > > Regards, > > Anthony > >
