For reference, this is where the docs are for the containers. http://libcloud.readthedocs.org/en/latest/container/index.html
Also, to note the approach here was instead of trying to come up with the perfect interface I'd put something together based on research, then incite feedback from our biggest users (some of which are commercial). Release early with (probably buggy) drivers as prototypes and get feedback on the API design. Anthony On Sat, Jan 30, 2016 at 8:50 AM, anthony shaw <anthonys...@apache.org> wrote: > Hey Guys > > Warm welcome! > > Ignasi- long time no speak :-) > > You raise some great questions. Forget about a docker standalone server for > now, although we do support that. > > The idea is to see a cluster or a cloud of docker servers, you can say > deploy x image(s) and list running containers. > > I've been speaking with some users of Docker at user groups and the > interesting use case is how do they develop a CI/CD process that can span > across Docker/Kubernetes (local private instance) and a public cloud? > > Differently clouds approach that in different ways. Joyent for example wraps > the docker API and provides compat, Amazon ECS provides an API to list > containers across a group of docker nodes. Kubernetes and Google cloud are > similar. > So we immediately have 4 different APIs for doing very similar tasks. > > Docker is to these providers what Xen or KVM was. The only way they will > provide value is to wrap services around the docker ecosystem. > > Also, Docker is not the only container spec, I don't know of any providers > running coreos yet but this is all moving so fast. > > I classified the drivers into 2 types. Those that are for a single container > host and those that are for a cluster of container hosts. ECS, Kubernetes > and GCE are the latter. > > With regards to deploying a graph of containers, each driver will have an > extension method for offering native actions, but I couldn't see any way of > doing that consistently yet. I would imagine defining a 'service' type with > a list of containers as an attribute and a simple reference to another > service it depends on would do the trick. > > Anthony > > Sent from Outlook Mobile > > _____________________________ > From: Andrew Phillips <andr...@apache.org> > Sent: Saturday, January 30, 2016 2:27 AM > Subject: Re: Hello from Apache Libcloud! > To: <dev@jclouds.apache.org> > > > >> Thanks for starting this thread! > > Big +1 to that - thanks, Anthony! What I'd be especially interested to > hear about are your thoughts on the feasibility of providing a level of > abstraction at this point. > > The main questions for me would be: > > * What is the right interface: something that can instantiate a single > image (e.g. Docker)? Or a graph of images (e.g. Kubernetes)? Or both? > > * How much commonality is there across providers? At present, the > "single image providers" seem much closer to providing a standard than > the "image graph providers"...but is the single image use case really > that compelling? > > * Given that the predominant paradigm for containers is "instantiate and > don't change" (vs. traditional compute, which is more like "instantiate > and modify"), what is the core value of an abstraction over multiple > providers - especially if they are largely all compatible with one API? > I.e. if all I'm trying to do is instantiate a known image, why not > simply use the Docker client or API directly? > > Would be great to learn more about how you see this space! > > Regards > > ap > >
