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
