Open Stack

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 <kraman at gmail.com> wrote:

>
> On Nov 18, 2013, at 4:30 PM, Russell Bryant <rbryant at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131121/39658425/attachment.html>