<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 21, 2013 at 9:58 AM, 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>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Will go over the options on the table briefly today. As we discussed during the design session, it will be important to figure out the delta between Nova VM API and what is required for containers. After we have the delta, we can decide on which of those 3 options makes sense.</div>
<div><br></div><div>--kr</div><div> </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>
>> 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>