On 11/18/2013 06:30 PM, Dan Smith wrote: >> Not having been at the summit (maybe the next one), could somebody >> give a really short explanation as to why it needs to be a separate >> service? It sounds like it should fit within the Nova area. It is, >> after all, just another hypervisor type, or so it seems. > > But it's not just another hypervisor. If all you want from your > containers is lightweight VMs, then nova is a reasonable place to put > that (and it's there right now). If, however, you want to expose the > complex and flexible attributes of a container, such as being able to > overlap filesystems, have fine-grained control over what is shared with > the host OS, look at the processes within a container, etc, then nova > ends up needing quite a bit of change to support that. > > I think the overwhelming majority of folks in the room, after discussing > it, agreed that Nova is infrastructure and containers is more of a > platform thing. Making it a separate service lets us define a mechanism > to manage these that makes much more sense than treating them like VMs. > Using Nova to deploy VMs that run this service is the right approach, > IMHO. Clayton put it very well, I think: > > If the thing you want to deploy has a kernel, then you need Nova. If > your thing runs on a kernel, you want $new_service_name. > > I agree. > > Note that this is just another service under the compute project (or > program, or whatever the correct terminology is this week).
The Compute program is correct. That is established terminology as defined by the TC in the last cycle. > So while > distinct from Nova in terms of code, development should be tightly > integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not "it *will* be a new service". Instead, it was, "we *think* it should be a new service, but let's do some more investigation to decide for sure". The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. 2) Declare containers as explicitly out of scope and start a new project with its own API. That is what is being proposed here. 3) Some middle ground that is a variation of #2. Consider Ironic. The idea is that Nova's API will still be used for basic provisioning, which Nova will implement by talking to Ironic. However, there are a lot of baremetal management things that don't fit in Nova at all, and those only exist in Ironic's API. I wanted to mention this option for completeness, but I don't actually think it's the right choice here. With Ironic you have a physical resource (managed by Ironic), and then instances of an image running on these physical resources (managed by Nova). With containers, there's a similar line. You have instances of containers (managed either by Nova or the new service) running on servers (managed by Nova). I think there is a good line for separating concerns, with a container service on top of Nova. Let's ask ourselves: How much overlap is there between the current compute API and a proposed containers API? Effectively, what's the diff? How much do we expect this diff to change in the coming years? The current diff demonstrates a significant clash with the current scope of Nova. I also expect a lot of innovation around containers in the next few years, which will result in wanting to do new cool things in the API. I feel that all of this justifies a new API service to best position ourselves for the long term. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
