Hi, A couple of notes on the progress here:
1) We are deprecating 4 providers, I don't think jclouds supports any of these, Verizon would also be added to that list but we never supported them http://libcloud.apache.org/blog/2016/02/16/new-drivers-deprecated-drivers.html 2) Also a blog post on the container support in v1. http://libcloud.apache.org/blog/2016/02/05/libcloud-containers-example.html Ant On Sat, Jan 30, 2016 at 6:07 PM, anthony shaw <anthony.p.s...@gmail.com> wrote: > 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 >> >>
