<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Nov 18, 2013, at 4:30 PM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On 11/18/2013 06:30 PM, Dan Smith wrote:<br><blockquote type="cite"><blockquote type="cite">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></blockquote><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 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></blockquote><br>The Compute program is correct. That is established terminology as<br>defined by the TC in the last cycle.<br><br><blockquote type="cite">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></blockquote><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 to<br>remove anyway). That presents a problem. A new service is one 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 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 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, 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 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></blockquote><div><br></div><div><div>+1 </div><div><br></div><div>We need to come up with the API first before we decide if this is a new service or just something that</div><div>needs to be added to Nova,</div><div><br></div><div>How about we have all interested parties meet on IRC or conf. call and discuss the suggested REST API, </div><div>open questions and architecture. <br><br>If you are interested please add your name to the participant list on <a href="https://etherpad.openstack.org/p/containers-service">https://etherpad.openstack.org/p/containers-service</a>.</div><div><br></div><div>I have also set up a doodle poll at <a href="http://doodle.com/w7y5qcdvq9i36757">http://doodle.com/w7y5qcdvq9i36757</a> to gather a times when a majority </div><div>of us are available to discuss on IRC.<br><br>--</div><div>Krishna Raman</div></div><div><br></div><div>PS: Sorry if you see this email twice. I am having some issues with list subscription.</div><br><blockquote type="cite"><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>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></body></html>