<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 21, 2013 at 12:58 PM, Sam Alba <span dir="ltr"><<a href="mailto:sam.alba@gmail.com" target="_blank">sam.alba@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman <<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>> wrote:<br>

><br>
> On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba <<a href="mailto:sam.alba@gmail.com">sam.alba@gmail.com</a>> wrote:<br>
>><br>
>> I wish we can make a decision during this meeting. Is it confirmed for<br>
>> Friday 9am pacific?<br>
><br>
><br>
> Friday 9am Pacific seems to be the best time for this meeting. Can we use<br>
> the #openstack-meeting channel for this?<br>
> If not, then I can find another channel.<br>
><br>
> For the agenda, I propose<br>
>  - going through <a href="https://etherpad.openstack.org/p/containers-service-api" target="_blank">https://etherpad.openstack.org/p/containers-service-api</a> and<br>
> understand capabilities of all container technologies<br>
>      + would like the experts on each of those technologies to fill us in<br>
>  - go over the API proposal and see what we need to change.<br>
<br>
</div>I think it's too early to go through the API. Let's first go through<br>
all options discussed before to support containers in openstack<br>
compute:<br>
#1 Have this new compute service for containers (other than Nova)<br>
#2 Extend Nova virt API to support containers<br>
#3 Support containers API as a third API for Nova<br>
<br>
Depending how it goes, then it makes sense to do an overview of the API I think.<br>
<br>
What do you guys think?<br></blockquote><div><br></div><div>+1 for me<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
>> On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short <<a href="mailto:chuck.short@canonical.com">chuck.short@canonical.com</a>><br>
>> wrote:<br>
>> > Hi<br>
>> ><br>
>> > Has a decision happened when this meeting is going to take place,<br>
>> > assuming<br>
>> > it is still taking place tomorrow.<br>
>> ><br>
>> > Regards<br>
>> > chuck<br>
>> ><br>
>> ><br>
>> > On Mon, Nov 18, 2013 at 7:58 PM, Krishna Raman <<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>> wrote:<br>
>> >><br>
>> >><br>
>> >> On Nov 18, 2013, at 4:30 PM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
>> >><br>
>> >> On 11/18/2013 06:30 PM, Dan Smith wrote:<br>
>> >><br>
>> >> Not having been at the summit (maybe the next one), could somebody<br>
>> >> give a really short explanation as to why it needs to be a separate<br>
>> >> service? It sounds like it should fit within the Nova area. It is,<br>
>> >> after all, just another hypervisor type, or so it seems.<br>
>> >><br>
>> >><br>
>> >> But it's not just another hypervisor. If all you want from your<br>
>> >> containers is lightweight VMs, then nova is a reasonable place to put<br>
>> >> that (and it's there right now). If, however, you want to expose the<br>
>> >> complex and flexible attributes of a container, such as being able to<br>
>> >> overlap filesystems, have fine-grained control over what is shared with<br>
>> >> the host OS, look at the processes within a container, etc, then nova<br>
>> >> ends up needing quite a bit of change to support that.<br>
>> >><br>
>> >> I think the overwhelming majority of folks in the room, after<br>
>> >> discussing<br>
>> >> it, agreed that Nova is infrastructure and containers is more of a<br>
>> >> platform thing. Making it a separate service lets us define a mechanism<br>
>> >> to manage these that makes much more sense than treating them like VMs.<br>
>> >> Using Nova to deploy VMs that run this service is the right approach,<br>
>> >> IMHO. Clayton put it very well, I think:<br>
>> >><br>
>> >>  If the thing you want to deploy has a kernel, then you need Nova. If<br>
>> >>  your thing runs on a kernel, you want $new_service_name.<br>
>> >><br>
>> >> I agree.<br>
>> >><br>
>> >> Note that this is just another service under the compute project (or<br>
>> >> program, or whatever the correct terminology is this week).<br>
>> >><br>
>> >><br>
>> >> The Compute program is correct.  That is established terminology as<br>
>> >> defined by the TC in the last cycle.<br>
>> >><br>
>> >> So while<br>
>> >> distinct from Nova in terms of code, development should be tightly<br>
>> >> integrated until (and if at some point) it doesn't make sense.<br>
>> >><br>
>> >><br>
>> >> And it may share a whole bunch of the code.<br>
>> >><br>
>> >> Another way to put this:  The API requirements people have for<br>
>> >> containers include a number of features considered outside of the<br>
>> >> current scope of Nova (short version: Nova's scope stops before going<br>
>> >> *inside* the servers it creates, except file injection, which we plan<br>
>> >> to<br>
>> >> remove anyway).  That presents a problem.  A new service is one<br>
>> >> possible<br>
>> >> solution.<br>
>> >><br>
>> >> My view of the outcome of the session was not "it *will* be a new<br>
>> >> service".  Instead, it was, "we *think* it should be a new service, but<br>
>> >> let's do some more investigation to decide for sure".<br>
>> >><br>
>> >> The action item from the session was to go off and come up with a<br>
>> >> proposal for what a new service would look like.  In particular, we<br>
>> >> needed a proposal for what the API would look like.  With that in hand,<br>
>> >> we need to come back and ask the question again of whether a new<br>
>> >> service<br>
>> >> is the right answer.<br>
>> >><br>
>> >> I see 3 possible solutions here:<br>
>> >><br>
>> >> 1) Expand the scope of Nova to include all of the things people want to<br>
>> >> be able to do with containers.<br>
>> >><br>
>> >> This is my least favorite option.  Nova is already really big.  We've<br>
>> >> worked to split things out (Networking, Block Storage, Images) to keep<br>
>> >> it under control.  I don't think a significant increase in scope is a<br>
>> >> smart move for Nova's future.<br>
>> >><br>
>> >> 2) Declare containers as explicitly out of scope and start a new<br>
>> >> project<br>
>> >> with its own API.<br>
>> >><br>
>> >> That is what is being proposed here.<br>
>> >><br>
>> >> 3) Some middle ground that is a variation of #2.  Consider Ironic.  The<br>
>> >> idea is that Nova's API will still be used for basic provisioning,<br>
>> >> which<br>
>> >> Nova will implement by talking to Ironic.  However, there are a lot of<br>
>> >> baremetal management things that don't fit in Nova at all, and those<br>
>> >> only exist in Ironic's API.<br>
>> >><br>
>> >> I wanted to mention this option for completeness, but I don't actually<br>
>> >> think it's the right choice here.  With Ironic you have a physical<br>
>> >> resource (managed by Ironic), and then instances of an image running on<br>
>> >> these physical resources (managed by Nova).<br>
>> >><br>
>> >> With containers, there's a similar line.  You have instances of<br>
>> >> containers (managed either by Nova or the new service) running on<br>
>> >> servers (managed by Nova).  I think there is a good line for separating<br>
>> >> concerns, with a container service on top of Nova.<br>
>> >><br>
>> >><br>
>> >> Let's ask ourselves:  How much overlap is there between the current<br>
>> >> compute API and a proposed containers API?  Effectively, what's the<br>
>> >> diff?  How much do we expect this diff to change in the coming years?<br>
>> >><br>
>> >> The current diff demonstrates a significant clash with the current<br>
>> >> scope<br>
>> >> of Nova.  I also expect a lot of innovation around containers in the<br>
>> >> next few years, which will result in wanting to do new cool things in<br>
>> >> the API.  I feel that all of this justifies a new API service to best<br>
>> >> position ourselves for the long term.<br>
>> >><br>
>> >><br>
>> >> +1<br>
>> >><br>
>> >> We need to come up with the API first before we decide if this is a new<br>
>> >> service or just something that<br>
>> >> needs to be added to Nova,<br>
>> >><br>
>> >> How about we have all interested parties meet on IRC or conf. call and<br>
>> >> discuss the suggested REST API,<br>
>> >> open questions and architecture.<br>
>> >><br>
>> >> If you are interested please add your name to the participant list on<br>
>> >> <a href="https://etherpad.openstack.org/p/containers-service" target="_blank">https://etherpad.openstack.org/p/containers-service</a>.<br>
>> >><br>
>> >> I have also set up a doodle poll at <a href="http://doodle.com/w7y5qcdvq9i36757" target="_blank">http://doodle.com/w7y5qcdvq9i36757</a><br>
>> >> to<br>
>> >> gather a times when a majority<br>
>> >> of us are available to discuss on IRC.<br>
>> >><br>
>> >> --<br>
>> >> Krishna Raman<br>
>> >><br>
>> >> PS: Sorry if you see this email twice. I am having some issues with<br>
>> >> list<br>
>> >> subscription.<br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Russell Bryant<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> OpenStack-dev mailing list<br>
>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> OpenStack-dev mailing list<br>
>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > OpenStack-dev mailing list<br>
>> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> @sam_alba<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
@sam_alba<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>