Hi Has a decision happened when this meeting is going to take place, assuming it is still taking place tomorrow.
Regards chuck On Mon, Nov 18, 2013 at 7:58 PM, Krishna Raman <kra...@gmail.com> wrote: > > On Nov 18, 2013, at 4:30 PM, Russell Bryant <rbry...@redhat.com> wrote: > > 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. > > > +1 > > We need to come up with the API first before we decide if this is a new > service or just something that > needs to be added to Nova, > > How about we have all interested parties meet on IRC or conf. call and > discuss the suggested REST API, > open questions and architecture. > > If you are interested please add your name to the participant list on > https://etherpad.openstack.org/p/containers-service. > > I have also set up a doodle poll at http://doodle.com/w7y5qcdvq9i36757 to > gather a times when a majority > of us are available to discuss on IRC. > > -- > Krishna Raman > > PS: Sorry if you see this email twice. I am having some issues with list > subscription. > > > -- > Russell Bryant > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
