On Thu, Nov 21, 2013 at 12:58 PM, Sam Alba <sam.a...@gmail.com> wrote:
> On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman <kra...@gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba <sam.a...@gmail.com> wrote: > >> > >> I wish we can make a decision during this meeting. Is it confirmed for > >> Friday 9am pacific? > > > > > > Friday 9am Pacific seems to be the best time for this meeting. Can we use > > the #openstack-meeting channel for this? > > If not, then I can find another channel. > > > > For the agenda, I propose > > - going through https://etherpad.openstack.org/p/containers-service-apiand > > understand capabilities of all container technologies > > + would like the experts on each of those technologies to fill us in > > - go over the API proposal and see what we need to change. > > I think it's too early to go through the API. Let's first go through > all options discussed before to support containers in openstack > compute: > #1 Have this new compute service for containers (other than Nova) > #2 Extend Nova virt API to support containers > #3 Support containers API as a third API for Nova > > Depending how it goes, then it makes sense to do an overview of the API I > think. > > What do you guys think? > +1 for me > > > >> On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short <chuck.sh...@canonical.com > > > >> wrote: > >> > 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 > >> > > >> > >> > >> > >> -- > >> @sam_alba > >> > >> _______________________________________________ > >> 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 > > > > > > -- > @sam_alba > > _______________________________________________ > 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
