The more I've used Containers in production the more I've come to the conclusion they are much different beasts then Nova Instances. Nova's abstraction lets Physical hardware and VM's share one common API, and it makes a lot of sense to unify them.
Oh. To be explicit, I'm talking about docker style lightweight containers, not heavy weight containers like LXC ones. The heavy weight ones do work well with Nova. For the rest of the conversation container = lightweight container. Trove can make use of containers provided there is a standard api in OpenStack for provisioning them. Right now, Magnum provides a way to get Kubernetes orchestrated clusters, for example, but doensn't have good integration with it to hook it into keystone so that Trusts can be used with it on the users behalf for advanced services like Trove. So some pieces are missing. Heat should have a way to have Kubernetes Yaml resources too. I think the recent request to rescope Kuryr to include non network features is a good step in solving some of the issues. Unfortunately, it will probably take some time to get Magnum to the point where it can be used by other OpenStack advanced services. Maybe these sorts of issues should be written down and discussed at the upcoming summit between the Magnum and Kuryr teams? Thanks, Kevin ________________________________________ From: Amrith Kumar [[email protected]] Sent: Monday, April 11, 2016 8:47 AM To: OpenStack Development Mailing List (not for usage questions); Allison Randal; Davanum Srinivas; [email protected] Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting) Monty, Dims, I read the notes and was similarly intrigued about the idea. In particular, from the perspective of projects like Trove, having a common Compute API is very valuable. It would allow the projects to have a single view of provisioning compute, as we can today with Nova and get the benefit of bare metal through Ironic, VM's through Nova VM's, and containers through nova-docker. With this in place, a project like Trove can offer database-as-a-service on a spectrum of compute infrastructures as any end-user would expect. Databases don't always make sense in VM's, and while containers are great for quick and dirty prototyping, and VM's are great for much more, there are databases that will in production only be meaningful on bare-metal. Therefore, if there is a move towards offering a common API for VM's, bare-metal and containers, that would be huge. Without such a mechanism, consuming containers in Trove adds considerable complexity and leads to a very sub-optimal architecture (IMHO). FWIW, a working prototype of Trove leveraging Ironic, VM's, and nova-docker to provision databases is something I worked on a while ago, and have not revisited it since then (once the direction appeared to be Magnum for containers). With all that said, I don't want to downplay the value in a container specific API. I'm merely observing that from the perspective of a consumer of computing services, a common abstraction is incredibly valuable. Thanks, -amrith > -----Original Message----- > From: Monty Taylor [mailto:[email protected]] > Sent: Monday, April 11, 2016 11:31 AM > To: Allison Randal <[email protected]>; Davanum Srinivas > <[email protected]>; [email protected] > Cc: OpenStack Development Mailing List (not for usage questions) > <[email protected]> > Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One > Platform – Containers/Bare Metal? (Re: Board of Directors Meeting) > > On 04/11/2016 09:43 AM, Allison Randal wrote: > >> On Wed, Apr 6, 2016 at 1:11 PM, Davanum Srinivas <[email protected]> > wrote: > >>> Reading unofficial notes [1], i found one topic very interesting: > >>> One Platform – How do we truly support containers and bare metal > >>> under a common API with VMs? (Ironic, Nova, adjacent communities e.g. > >>> Kubernetes, Apache Mesos etc) > >>> > >>> Anyone present at the meeting, please expand on those few notes on > >>> etherpad? And how if any this feedback is getting back to the > >>> projects? > > > > It was really two separate conversations that got conflated in the > > summary. One conversation was just being supportive of bare metal, > > VMs, and containers within the OpenStack umbrella. The other > > conversation started with Monty talking about his work on shade, and > > how it wouldn't exist if more APIs were focused on the way users > > consume the APIs, and less an expression of the implementation details > of each project. > > OpenStackClient was mentioned as a unified CLI for OpenStack focused > > more on the way users consume the CLI. (OpenStackSDK wasn't mentioned, > > but falls in the same general category of work.) > > > > i.e. There wasn't anything new in the conversation, it was more a > > matter of the developers/TC members on the board sharing information > > about work that's already happening. > > I agree with that - but would like to clarify the 'bare metal, VMs and > containers' part a bit. (an in fact, I was concerned in the meeting that > the messaging around this would be confusing because we 'supporting bare > metal' and 'supporting containers' mean two different things but we use > one phrase to talk about it. > > It's abundantly clear at the strategic level that having OpenStack be able > to provide both VMs and Bare Metal as two different sorts of resources > (ostensibly but not prescriptively via nova) is one of our advantages. We > wanted to underscore how important it is to be able to do that, and wanted > to underscore that so that it's really clear how important it is any time > the "but cloud should just be VMs" sentiment arises. > > The way we discussed "supporting containers" was quite different and was > not about nova providing containers. Rather, it was about reaching out to > our friends in other communities and working with them on making OpenStack > the best place to run things like kubernetes or docker swarm. > Those are systems that ultimately need to run, and it seems that good > integration (like kuryr with libnetwork) can provide a really strong > story. I think pretty much everyone agrees that there is not much value to > us or the world for us to compete with kubernetes or docker. > > So, we do want to be supportive of bare metal and containers - but the > specific _WAY_ we want to be supportive of those things is different for > each one. > > Monty > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
