Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Krishna Raman]

On Dec 13, 2013 12:20 PM, "Eric Windisch"  wrote:
>
> On Fri, Dec 13, 2013 at 1:19 PM, Chuck Short 
wrote:
>>
>> Hi,
>>
>> I have definitely seen a drop off in the proposed Container-Service API
discussion
>
>
> There was only one action item from the meeting, which was a compilation
of use-cases from Krishna.
>
> Krishna, have you made progress on the use-cases? Is there a wiki page?

I have some and will post them along with a new doodle poll for another
meeting soon.

Thanks for the reminder :)

-kr

>
> Regards,
> Eric Windisch
>
>
> ___
> 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

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Eric Windisch]

On Fri, Dec 13, 2013 at 1:19 PM, Chuck Short wrote:

> Hi,
>
> I have definitely seen a drop off in the proposed Container-Service API
> discussion
>

There was only one action item from the meeting, which was a compilation of
use-cases from Krishna.

Krishna, have you made progress on the use-cases? Is there a wiki page?

Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Chuck Short]

Hi,

I have definitely seen a drop off in the proposed Container-Service API
discussion. I think peple are still mauling over the ideas that were
presented so far. However with looking at the discussion so far, and
possibly trying to get the discussion going again, I don't think we are at
the point where a totally separate Container-Service API is needed yet.

Regards
chuck


On Thu, Dec 12, 2013 at 12:59 PM, Rick Harris wrote:

> Hi all,
>
> Was wondering if there's been any more work done on the proposed
> Container-Service (Capsule?) API?
>
> Haven't seen much on the ML on this, so just want to make sure the current
> plan is still to have a draft of the Capsule API, compare the delta to the
> existing Nova API, and determine whether a separate service still makes
> sense for the current use-cases.
>
> Thanks!
>
> Rick
>
>
> On Fri, Nov 22, 2013 at 2:35 PM, Russell Bryant wrote:
>
>> On 11/22/2013 02:29 PM, Krishna Raman wrote:
>> >
>> > On Nov 22, 2013, at 10:26 AM, Eric Windisch > > > wrote:
>> >
>> >> On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman > >> > wrote:
>> >>> Reminder: We are meting in about 15 minutes on #openstack-meeting
>> >>> channel.
>> >>
>> >> I wasn't able to make it. Was meeting-bot triggered? Is there a log of
>> >> today's discussion?
>> >
>> > Yes. Logs are
>> > here:
>> http://eavesdrop.openstack.org/meetings/nova/2013/nova.2013-11-22-17.01.log.html
>>
>> Yep, I used the 'nova' meeting topic for this one.  If the meeting turns
>> in to a regular thing, we should probably switch it to some sort of
>> sub-team type name ... like nova-containers.
>>
>> --
>> 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

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Rick Harris]

Hi all,

Was wondering if there's been any more work done on the proposed
Container-Service (Capsule?) API?

Haven't seen much on the ML on this, so just want to make sure the current
plan is still to have a draft of the Capsule API, compare the delta to the
existing Nova API, and determine whether a separate service still makes
sense for the current use-cases.

Thanks!

Rick


On Fri, Nov 22, 2013 at 2:35 PM, Russell Bryant  wrote:

> On 11/22/2013 02:29 PM, Krishna Raman wrote:
> >
> > On Nov 22, 2013, at 10:26 AM, Eric Windisch  > > wrote:
> >
> >> On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman  >> > wrote:
> >>> Reminder: We are meting in about 15 minutes on #openstack-meeting
> >>> channel.
> >>
> >> I wasn't able to make it. Was meeting-bot triggered? Is there a log of
> >> today's discussion?
> >
> > Yes. Logs are
> > here:
> http://eavesdrop.openstack.org/meetings/nova/2013/nova.2013-11-22-17.01.log.html
>
> Yep, I used the 'nova' meeting topic for this one.  If the meeting turns
> in to a regular thing, we should probably switch it to some sort of
> sub-team type name ... like nova-containers.
>
> --
> 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

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Russell Bryant]

On 11/22/2013 02:29 PM, Krishna Raman wrote:
> 
> On Nov 22, 2013, at 10:26 AM, Eric Windisch  > wrote:
> 
>> On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman > > wrote:
>>> Reminder: We are meting in about 15 minutes on #openstack-meeting
>>> channel.
>>
>> I wasn't able to make it. Was meeting-bot triggered? Is there a log of
>> today's discussion?
> 
> Yes. Logs are
> here: 
> http://eavesdrop.openstack.org/meetings/nova/2013/nova.2013-11-22-17.01.log.html

Yep, I used the 'nova' meeting topic for this one.  If the meeting turns
in to a regular thing, we should probably switch it to some sort of
sub-team type name ... like nova-containers.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Krishna Raman]

On Nov 22, 2013, at 10:26 AM, Eric Windisch  wrote:

> On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman  wrote:
>> Reminder: We are meting in about 15 minutes on #openstack-meeting channel.
> 
> I wasn't able to make it. Was meeting-bot triggered? Is there a log of
> today's discussion?

Yes. Logs are here: 
http://eavesdrop.openstack.org/meetings/nova/2013/nova.2013-11-22-17.01.log.html

> 
> Thank you,
> Eric Windisch
> 
> ___
> 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

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Eric Windisch]

On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman  wrote:
> Reminder: We are meting in about 15 minutes on #openstack-meeting channel.

I wasn't able to make it. Was meeting-bot triggered? Is there a log of
today's discussion?

Thank you,
Eric Windisch

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Krishna Raman]

Reminder: We are meting in about 15 minutes on #openstack-meeting channel.

--Krishna


On Fri, Nov 22, 2013 at 7:53 AM, Krishna Raman  wrote:

>
>
>
> On Thu, Nov 21, 2013 at 11:07 AM, Tim Bell  wrote:
>
>>
>>
>> Can we make sure that the costs for the end users are also considered as
>> part of this ?
>>
>>
>>
>> -  Configuration management will need further modules
>>
>> -  Dashboard confusion as we get multiple tabs
>>
>> -  Accounting, Block Storage, Networking, Orchestration
>> confusion as the concepts diverge
>>
>>
>>
>> Is this really a good idea to create another project considering the
>> needs of the whole openstack community ?
>>
>
> Hi Tim,
>
> We have not made the determination that a new service is necessary yet.
> All the discussion today will be about is to see what the differences are.
> After we have that, we will go back to discuss with Nova team and see if
> the split is even necessary.
>
> --kr
>
>
>>
>>
>> Tim
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Clint Byrum]

Excerpts from Thierry Carrez's message of 2013-11-22 01:50:39 -0800:
> Tim Bell wrote:
> > Can we make sure that the costs for the end users are also considered as
> > part of this ?
> > 
> > -  Configuration management will need further modules
> > -  Dashboard confusion as we get multiple tabs
> > -  Accounting, Block Storage, Networking, Orchestration
> > confusion as the concepts diverge
> > 
> > Is this really a good idea to create another project considering the
> > needs of the whole openstack community ?
> 
> Personally, it will have to prove a really different API and set of use
> cases to justify the cost of a separate project. I'm waiting to see what
> they come up with, but IMHO it's "compute" in both cases. We've seen
> with the libvirt-sandbox discussion that using technology (hypervisor
> vs. container) to draw the line between the use cases is a bit
> over-simplifying the problem.
> 

Agreed, I think it has been over simplified, but that is what you do
when you're not driven by a well understood real use-case, something I
have yet to see from this discussion.

> I don't really want us to create a container service and end up
> implementing the same hypervisor backends than in Nova, just because
> hypervisors can perfectly also be used to serve lightweight
> application-centric workloads. Or the other way around (keep Docker
> support in Nova since you can perfectly run an OS in a container). At
> first glance, extending the Nova API to also cover lightweight
> app-centric use cases would avoid a ton of duplication...
> 

Agreed. There are a few weird things that come to mind though. One of
those is that I imagine users would like to do something like this:

host_id=$(container-thing allocate-host --flavor small  appserver)
db_id=$(container-thing allocate-host --flavor huge dbserver)
app_id=$(container-thing run --host $host_id --image app-image)
proxy_id=$(container-thing run --host $host_id --image proxy-image)
cache_id=$(container-thing run --host $host_id --image cache-image)
db_id=$(container-thing run --host $db_id)

As in, they'd probably like to have VMs spun up and then chopped up
into containers. If this is implemented first inside nova, that may end
up being a rats nest and hard to separate later.  The temptation to use
private API's is really strong. But if it is outside nova, the separation
stays clear and the two can be used without one-another very easily.

> If the main concern is to keep Nova small and manageable, I'd rather rip
> out pieces like nova-network or the scheduler, which are clearly not
> "compute".
> 

Indeed, and those things are under way. :)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Krishna Raman]

On Thu, Nov 21, 2013 at 9:58 AM, Sam Alba  wrote:

> On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman  wrote:
> >
> > On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba  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?
>
>
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.

--kr


>
> >> On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short  >
> >> 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 
> wrote:
> >> >>
> >> >>
> >> >> On Nov 18, 2013, at 4:30 PM, Russell Bryant 
> 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 poss

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Krishna Raman]

On Thu, Nov 21, 2013 at 11:07 AM, Tim Bell  wrote:

>
>
> Can we make sure that the costs for the end users are also considered as
> part of this ?
>
>
>
> -  Configuration management will need further modules
>
> -  Dashboard confusion as we get multiple tabs
>
> -  Accounting, Block Storage, Networking, Orchestration confusion
> as the concepts diverge
>
>
>
> Is this really a good idea to create another project considering the needs
> of the whole openstack community ?
>

Hi Tim,

We have not made the determination that a new service is necessary yet. All
the discussion today will be about is to see what the differences are.
After we have that, we will go back to discuss with Nova team and see if
the split is even necessary.

--kr


>
>
> Tim
>
>
>
>
>
>
>
> ___
> 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

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Thierry Carrez]

Tim Bell wrote:
> Can we make sure that the costs for the end users are also considered as
> part of this ?
> 
> -  Configuration management will need further modules
> -  Dashboard confusion as we get multiple tabs
> -  Accounting, Block Storage, Networking, Orchestration
> confusion as the concepts diverge
> 
> Is this really a good idea to create another project considering the
> needs of the whole openstack community ?

Personally, it will have to prove a really different API and set of use
cases to justify the cost of a separate project. I'm waiting to see what
they come up with, but IMHO it's "compute" in both cases. We've seen
with the libvirt-sandbox discussion that using technology (hypervisor
vs. container) to draw the line between the use cases is a bit
over-simplifying the problem.

I don't really want us to create a container service and end up
implementing the same hypervisor backends than in Nova, just because
hypervisors can perfectly also be used to serve lightweight
application-centric workloads. Or the other way around (keep Docker
support in Nova since you can perfectly run an OS in a container). At
first glance, extending the Nova API to also cover lightweight
app-centric use cases would avoid a ton of duplication...

If the main concern is to keep Nova small and manageable, I'd rather rip
out pieces like nova-network or the scheduler, which are clearly not
"compute".

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Chuck Short]

On Thu, Nov 21, 2013 at 12:58 PM, Sam Alba  wrote:

> On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman  wrote:
> >
> > On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba  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  >
> >> 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 
> wrote:
> >> >>
> >> >>
> >> >> On Nov 18, 2013, at 4:30 PM, Russell Bryant 
> 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 (

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Chuck Short]

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  wrote:

>
> On Nov 18, 2013, at 4:30 PM, Russell Bryant  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

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Tim Bell]

Can we make sure that the costs for the end users are also considered as part 
of this ?


-  Configuration management will need further modules

-  Dashboard confusion as we get multiple tabs

-  Accounting, Block Storage, Networking, Orchestration confusion as 
the concepts diverge

Is this really a good idea to create another project considering the needs of 
the whole openstack community ?

Tim



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Rick Harris]

Sounds good to me, let's get everyone on the same page before diving into
the weeds.

That said, since so much depends on the delta to the Nova API and the
actual use-cases we want to support, think we should spend at least some
time focusing on the direction (and maybe even the details?) that that the
proposed API is taking.


On Thu, Nov 21, 2013 at 11:58 AM, Sam Alba  wrote:

> On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman  wrote:
> >
> > On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba  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?
>
>
> >> On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short  >
> >> 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 
> wrote:
> >> >>
> >> >>
> >> >> On Nov 18, 2013, at 4:30 PM, Russell Bryant 
> 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

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Rick Harris]

++ on Fri. 9am PST.


On Thu, Nov 21, 2013 at 10:57 AM, Sam Alba  wrote:

> I wish we can make a decision during this meeting. Is it confirmed for
> Friday 9am pacific?
>
> On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short 
> 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  wrote:
> >>
> >>
> >> On Nov 18, 2013, at 4:30 PM, Russell Bryant  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?  Effecti

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Krishna Raman]

On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba  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.

--Krishna


>
> On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short 
> 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  wrote:
> >>
> >>
> >> On Nov 18, 2013, at 4:30 PM, Russell Bryant  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 resour

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Sam Alba]

On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman  wrote:
>
> On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba  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-api and
> 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?


>> On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short 
>> 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  wrote:
>> >>
>> >>
>> >> On Nov 18, 2013, at 4:30 PM, Russell Bryant  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 he

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Sam Alba]

I wish we can make a decision during this meeting. Is it confirmed for
Friday 9am pacific?

On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short  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  wrote:
>>
>>
>> On Nov 18, 2013, at 4:30 PM, Russell Bryant  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 

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Russell Bryant]

On 11/19/2013 03:08 PM, Rick Jones wrote:
> On 11/19/2013 10:02 AM, James Bottomley wrote:
>> It is possible to extend the Nova APIs to control containers more fully,
>> but there was resistance do doing this on the grounds that it's
>> expanding the scope of Nova, hence the new project.
> 
> How well received would another CLI/API to learn be among the end-users?

It depends.  It is it mostly a duplication of the compute API, but just
slightly different enough to be annoying?  Or is it something
significantly different enough that much better suits their use cases?

That's the important question to answer here.  How different is it, and
does the difference justify a split?

The opinions so far are quite vast.  Those interested in pushing this
are going to go off and work on a more detailed API proposal.  I think
we should revisit this discussion when they have something for us to
evaluate against.

Even if this ends up staying in Nova, the API work is still useful.  It
would help us toward defining a container specific extension to the
compute API.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Rick Jones]

On 11/19/2013 10:02 AM, James Bottomley wrote:

It is possible to extend the Nova APIs to control containers more fully,
but there was resistance do doing this on the grounds that it's
expanding the scope of Nova, hence the new project.


How well received would another CLI/API to learn be among the end-users?

rick jones

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Daniel P. Berrange]

On Tue, Nov 19, 2013 at 10:02:45AM -0800, James Bottomley wrote:
> On Mon, 2013-11-18 at 14:28 -0800, Stuart Fox wrote:
> > Hey all
> > 
> > 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.
> 
> I can take a stab at this:  Firstly, a container is *not* a hypervisor.
> Hypervisor based virtualisation is done at the hardware level (so with
> hypervisors you boot a second kernel on top of the virtual hardware),
> container based virtualisation is done at the OS (kernel) level (so all
> containers share the same kernel ... and sometimes even huge chunks of
> the OS). With recent advances in the Linux Kernel, we can make a
> container behave like a hypervisor (full OS/IaaS virtualisation), but
> quite a bit of the utility of containers is that they can do much more
> than hypervisors, so they shouldn't be constrained by hypervisor APIs
> (which are effectively virtual hardware APIs).
> 
> It is possible to extend the Nova APIs to control containers more fully,
> but there was resistance do doing this on the grounds that it's
> expanding the scope of Nova, hence the new project.

You're focusing on the low level technical differences between containers
and hypervisor here which IMHO is not the right comparison to be making.
Once you look at the high level use cases many of the referenced container
virt apps are trying to address things don't look anywhere near as clear
cut. As mentioned elsewhere libvirt-sandbox which provides a application
sandboxing toolkit is able to leverage either LXC or KVM virt to achieve
its high level goals. Based on my understanding of Docker, I believe it
would actually be possible to run Docker images under KVM without much
difficultly. There will certainly be some setups that aren't possible
todo with hypervisors, but I don't think those will be in the majority,
nor require starting again from scratch, throwing out Nova.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[James Bottomley]

On Tue, 2013-11-19 at 13:46 -0500, Eric Windisch wrote:
> On Tue, Nov 19, 2013 at 1:02 PM, James Bottomley
>  wrote:
> > On Mon, 2013-11-18 at 14:28 -0800, Stuart Fox wrote:
> >> Hey all
> >>
> >> 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.
> >
> > I can take a stab at this:  Firstly, a container is *not* a hypervisor.
> > Hypervisor based virtualisation is done at the hardware level (so with
> > hypervisors you boot a second kernel on top of the virtual hardware),
> > container based virtualisation is done at the OS (kernel) level (so all
> > containers share the same kernel ... and sometimes even huge chunks of
> > the OS). With recent advances in the Linux Kernel, we can make a
> > container behave like a hypervisor (full OS/IaaS virtualisation), but
> > quite a bit of the utility of containers is that they can do much more
> > than hypervisors, so they shouldn't be constrained by hypervisor APIs
> > (which are effectively virtual hardware APIs).
> >
> > It is possible to extend the Nova APIs to control containers more fully,
> > but there was resistance do doing this on the grounds that it's
> > expanding the scope of Nova, hence the new project.
> 
> It might be worth noting that it was also brought up that
> hypervisor-based virtualization can offer a number of features that
> bridge some of these gaps, but are not supported in, nor may ever be
> supported in Nova.
> 
> For example, Daniel brings up an interesting point with the
> libvirt-sandbox feature. This is one of those features that bridges
> some of the gaps. There are also solutions, however brittle, for
> introspection that work on hypervisor-driven VMs. It is not clear what
> the scope or desire for these features might be, how they might be
> sufficiently abstracted between hypervisors and guest OSes, nor how
> these would fit into any of the existing or planned compute API
> buckets.

It's certainly possible, but some of them are possible in the same way
as it's possible to get a square peg into a round hole by beating the
corners flat with a sledge hammer ... it works, but it's much less
hassle just to use a round peg because it actually fits the job.

> Having a separate service for managing containers draws a thick line
> in the sand that will somewhat stiffen innovation around
> hypervisor-based virtualization. That isn't necessarily a bad thing,
> it will help maintain stability in the project. However, the choice
> and the implications shouldn't be ignored.

How about this: we get the container API agreed and we use a driver
model like Nova (we have to anyway since there about four different
container technologies interested in this), then we see if someone wants
to do a hypervisor driver emulating the features.

James



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Eric Windisch]

On Tue, Nov 19, 2013 at 1:02 PM, James Bottomley
 wrote:
> On Mon, 2013-11-18 at 14:28 -0800, Stuart Fox wrote:
>> Hey all
>>
>> 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.
>
> I can take a stab at this:  Firstly, a container is *not* a hypervisor.
> Hypervisor based virtualisation is done at the hardware level (so with
> hypervisors you boot a second kernel on top of the virtual hardware),
> container based virtualisation is done at the OS (kernel) level (so all
> containers share the same kernel ... and sometimes even huge chunks of
> the OS). With recent advances in the Linux Kernel, we can make a
> container behave like a hypervisor (full OS/IaaS virtualisation), but
> quite a bit of the utility of containers is that they can do much more
> than hypervisors, so they shouldn't be constrained by hypervisor APIs
> (which are effectively virtual hardware APIs).
>
> It is possible to extend the Nova APIs to control containers more fully,
> but there was resistance do doing this on the grounds that it's
> expanding the scope of Nova, hence the new project.

It might be worth noting that it was also brought up that
hypervisor-based virtualization can offer a number of features that
bridge some of these gaps, but are not supported in, nor may ever be
supported in Nova.

For example, Daniel brings up an interesting point with the
libvirt-sandbox feature. This is one of those features that bridges
some of the gaps. There are also solutions, however brittle, for
introspection that work on hypervisor-driven VMs. It is not clear what
the scope or desire for these features might be, how they might be
sufficiently abstracted between hypervisors and guest OSes, nor how
these would fit into any of the existing or planned compute API
buckets.

Having a separate service for managing containers draws a thick line
in the sand that will somewhat stiffen innovation around
hypervisor-based virtualization. That isn't necessarily a bad thing,
it will help maintain stability in the project. However, the choice
and the implications shouldn't be ignored.

-- 
Regards,
Eric Windisch

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Sam Alba]

On Tue, Nov 19, 2013 at 6:45 AM, Chuck Short  wrote:
> Hi
>
> I am excited to see containers getting such traction in the openstack
> project.
>
>
> On Mon, Nov 18, 2013 at 7:30 PM, Russell Bryant  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.
>>
>
> This is my least favorite option. Like a lot of other responses already I
> see a lot of code duplication  because Nova and the new nova container's
> project. This just doesn't include the scheduler but  things like config
> driver, etc.

Can we dig into this option? Honestly, I'd be glad to find a way to
avoid reimplementing everything again (a new compute service with
Keystone, Glance, Horizon integration, etc...). But I do understand
the limitation of changing Nova to improve containers support.

Can someone bring more details (maybe in the spec etherpad, in a new
section) about this 3rd option?

Since the API (in the front) and the virt API (in the back) have to be
different, I barely see how we can reuse most of Nova's code.

>>
>> 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.
>
>
> This is my preferred choice  as well. If we could leverage the existing nova
> API and extend it to include containers and features that users who use
> containers in their existing production environment wants.
>>
>>
>> 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

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[James Bottomley]

On Mon, 2013-11-18 at 14:28 -0800, Stuart Fox wrote:
> Hey all
> 
> 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.

I can take a stab at this:  Firstly, a container is *not* a hypervisor.
Hypervisor based virtualisation is done at the hardware level (so with
hypervisors you boot a second kernel on top of the virtual hardware),
container based virtualisation is done at the OS (kernel) level (so all
containers share the same kernel ... and sometimes even huge chunks of
the OS). With recent advances in the Linux Kernel, we can make a
container behave like a hypervisor (full OS/IaaS virtualisation), but
quite a bit of the utility of containers is that they can do much more
than hypervisors, so they shouldn't be constrained by hypervisor APIs
(which are effectively virtual hardware APIs).

It is possible to extend the Nova APIs to control containers more fully,
but there was resistance do doing this on the grounds that it's
expanding the scope of Nova, hence the new project.

James



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Chuck Short]

Hi

I am excited to see containers getting such traction in the openstack
project.


On Mon, Nov 18, 2013 at 7:30 PM, Russell Bryant  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.
>
>
This is my least favorite option. Like a lot of other responses already I
see a lot of code duplication  because Nova and the new nova container's
project. This just doesn't include the scheduler but  things like config
driver, etc.


> 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.
>

This is my preferred choice  as well. If we could leverage the existing
nova API and extend it to include containers and features that users who
use containers in their existing production environment wants.

>
> 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 cu

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Daniel P. Berrange]

On Tue, Nov 19, 2013 at 10:57:51AM +0100, Thierry Carrez wrote:
> Russell Bryant wrote:
> > 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.
> 
> +1
> 
> I can see how a separate service can be a good way to avoid making Nova
> support container-specific use cases and make it even bigger than it is.
> However if you end up duplicating most of the code, I'm not sure there
> would be any net gain.
> 
> I'm not talking about the base service infrastructure and the scheduler
> (which are well-known duplication already) but more around specific nova
> features (metadata/config drive, networking, image handling, etc.) that
> would apply to VMs and containers alike.
> 
> So it would be great to come out of this first round of analysis with a
> plan detailing how different (and how similar) from nova that new
> service would be, and how much code duplication is to be expected.

Yep, I'm far from convinced that having a separate service for
containers is going to be a net gain for the project as a whole.
It seems to me that we're likely to have an API and codebase that
is 95% the same in both cases here, with most differences just
being about the way things are initially booted/provisioned.

While containers certainly have some unique attributes, I believe
the level of differentiation is overblown. I also think the difference
is not about  containers vs VMs, but rather about OS virtualization vs
application virtualization.

It is entirely practical to do application virtualization using
either containers or VMs, as demonstrated by libvirt-sandbox which
can run individual app processes inside KVM without needing a full
OS intsall for it. There are notable security advantages to using
KVM for application virtualization since it avoids the shared kernel
single point of failure/compromise.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Thierry Carrez]

Russell Bryant wrote:
> 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.

+1

I can see how a separate service can be a good way to avoid making Nova
support container-specific use cases and make it even bigger than it is.
However if you end up duplicating most of the code, I'm not sure there
would be any net gain.

I'm not talking about the base service infrastructure and the scheduler
(which are well-known duplication already) but more around specific nova
features (metadata/config drive, networking, image handling, etc.) that
would apply to VMs and containers alike.

So it would be great to come out of this first round of analysis with a
plan detailing how different (and how similar) from nova that new
service would be, and how much code duplication is to be expected.

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Daniel P. Berrange]

On Mon, Nov 18, 2013 at 07:10:53PM -0500, Krishna Raman wrote:
> We should probably meet on IRC or conf. call and discuss the suggested 
> architecture, open questions and REST API.
> 
> I have set up a doodle poll at http://doodle.com/w7y5qcdvq9i36757 to gather a 
> times when we can meet.
> Please sign up or let me know if none of the time slots works for you.

The time slots are pretty west coast centric there. Only the 8am/9am slots
work for people in Europe really.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Krishna Raman]

On Nov 18, 2013, at 6:05 PM, Russell Bryant  wrote:

> On 11/18/2013 07:58 PM, Krishna Raman wrote:
>> 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.
> 
> What time zone are these times in?
> 

Sorry forgot to mention. These times are in Pacific time zone.
http://www.time.gov/timezone.cgi?Pacific/d/-8

—Krishna

> -- 
> 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

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Russell Bryant]

On 11/18/2013 07:58 PM, Krishna Raman wrote:
> 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.

What time zone are these times in?

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Krishna Raman]

On Nov 18, 2013, at 4:30 PM, Russell Bryant  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. 

I

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Russell Bryant]

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.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Clint Byrum]

Excerpts from Sam Alba's message of 2013-11-18 14:05:47 -0800:
> Hello everyone,
> 
> As some of you already know - in Hong-Kong during the last OpenStack
> Summit - we ran a design session in the Nova topic titled "Docker
> support in OpenStack". The session concluded in developing a new
> OpenStack service for supporting containers instead of modifying Nova
> to support both VMs and containers.
> 
> As said earlier, I am proposing a first draft of the spec for the
> service. I've explicitly CC'ed all people who signed up at the end of
> the design session.
> 
> Here is it: https://etherpad.openstack.org/p/containers-service
> 
> Once we agree on the HTTP API and on the plugin API, the idea is to
> implement a first simple version that would support mono-host. Then it
> would evolve in multi-host really quickly by adding a scheduler and a
> messaging layer (more details in the etherpad).
> 

This is cool and I agree that having containers as a service makes more
sense for a number of reasons.

However, you have not included any concrete use cases in the etherpad
above.

Things without real world use cases tend to devolve quickly into coding
parties IMO. "Oh look at the lovely spec and implementation we are
making." Meanwhile the real users with real use cases are hard to get
right and thus end up going elsewhere because they are "proposing hacks".

Also, I would love to see the first implementation of multi-node take
the gearman route and just have "workers" (compute-equivalent) register
their container capabilities and clients (API servers) push container
jobs into those capability queues.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Dan Smith]

> 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). 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.

--Dan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Monty Taylor]

On 11/18/2013 02:28 PM, Stuart Fox wrote:
> Hey all
> 
> 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.

I was at the summit, but wasn't at this.

I _think_ I grok a bit of why it's another service, sort of, but also
sort of don't, depending on what it is exactly that we're talking about.

Let me state things I think I understand:

- In addition to using containers like we use VMs, it's also possible to
use containers to just run specific processes. This is one of the the
things this service would help model.

- nova boot would still be the way you'd potentially get a container if
what you wanted was a 'full machine' like thing

Right ish?


> (I can’t find the justification on the OS site)
> 
> ---
> BR,
> Stuart Fox
> Manager, Systems Engineering
> Demonware
> +17783753701
> 
> On Nov 18, 2013, at 2:05 PM, Sam Alba  wrote:
> 
>> Hello everyone,
>>
>> As some of you already know - in Hong-Kong during the last OpenStack
>> Summit - we ran a design session in the Nova topic titled "Docker
>> support in OpenStack". The session concluded in developing a new
>> OpenStack service for supporting containers instead of modifying Nova
>> to support both VMs and containers.
>>
>> As said earlier, I am proposing a first draft of the spec for the
>> service. I've explicitly CC'ed all people who signed up at the end of
>> the design session.
>>
>> Here is it: https://etherpad.openstack.org/p/containers-service
>>
>> Once we agree on the HTTP API and on the plugin API, the idea is to
>> implement a first simple version that would support mono-host. Then it
>> would evolve in multi-host really quickly by adding a scheduler and a
>> messaging layer (more details in the etherpad).
>>
>> Please have a look if you're interested in using Containers (and
>> Docker) in OpenStack.
>>
>> Thanks Russell for giving some early feedback.
>>
>> Also, Krishna Raman from RedHat already gave a first shot at drafting
>> the Rest API:
>>
>> https://etherpad.openstack.org/p/containers-service-api
>>
>>
>> Sam
>>
>> -- 
>> @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
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Joshua Harlow]

Same question here. I also wonder why a new service. Yes the capabilities
might be different (but then can't this be fixed this is nova by making
nova support different capabilities in different hypervisors better). The
api's also might be different (but then can't this be fixed by making the
api plugins more comprehensive, perhaps attached to the capabilities
somehow). 

I go back to an example (maybe a bad one) that if u think of nova as a
project similar to eclipse (not really, just a temporary analogy). If u
have used eclipse there exists have whole plugins into eclipse which
drastically alter how and what eclipse offers. If nova was more like
eclipse (at least in this aspect) then couldn't there be a set of plugins
that could be added that would add or remove container support, and nova
would provide the core foundation eclipse platform (maybe stretching the
analogy too far here).

Just a think to think about.

-Josh

On 11/18/13 2:28 PM, "Stuart Fox"  wrote:

>Hey all
>
>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.
>
>(I can¹t find the justification on the OS site)
>
>---
>BR,
>Stuart Fox
>Manager, Systems Engineering
>Demonware
>+17783753701
>
>On Nov 18, 2013, at 2:05 PM, Sam Alba  wrote:
>
>> Hello everyone,
>> 
>> As some of you already know - in Hong-Kong during the last OpenStack
>> Summit - we ran a design session in the Nova topic titled "Docker
>> support in OpenStack". The session concluded in developing a new
>> OpenStack service for supporting containers instead of modifying Nova
>> to support both VMs and containers.
>> 
>> As said earlier, I am proposing a first draft of the spec for the
>> service. I've explicitly CC'ed all people who signed up at the end of
>> the design session.
>> 
>> Here is it: https://etherpad.openstack.org/p/containers-service
>> 
>> Once we agree on the HTTP API and on the plugin API, the idea is to
>> implement a first simple version that would support mono-host. Then it
>> would evolve in multi-host really quickly by adding a scheduler and a
>> messaging layer (more details in the etherpad).
>> 
>> Please have a look if you're interested in using Containers (and
>> Docker) in OpenStack.
>> 
>> Thanks Russell for giving some early feedback.
>> 
>> Also, Krishna Raman from RedHat already gave a first shot at drafting
>> the Rest API:
>> 
>> https://etherpad.openstack.org/p/containers-service-api
>> 
>> 
>> Sam
>> 
>> -- 
>> @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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Stuart Fox]

Hey all

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.

(I can’t find the justification on the OS site)

---
BR,
Stuart Fox
Manager, Systems Engineering
Demonware
+17783753701

On Nov 18, 2013, at 2:05 PM, Sam Alba  wrote:

> Hello everyone,
> 
> As some of you already know - in Hong-Kong during the last OpenStack
> Summit - we ran a design session in the Nova topic titled "Docker
> support in OpenStack". The session concluded in developing a new
> OpenStack service for supporting containers instead of modifying Nova
> to support both VMs and containers.
> 
> As said earlier, I am proposing a first draft of the spec for the
> service. I've explicitly CC'ed all people who signed up at the end of
> the design session.
> 
> Here is it: https://etherpad.openstack.org/p/containers-service
> 
> Once we agree on the HTTP API and on the plugin API, the idea is to
> implement a first simple version that would support mono-host. Then it
> would evolve in multi-host really quickly by adding a scheduler and a
> messaging layer (more details in the etherpad).
> 
> Please have a look if you're interested in using Containers (and
> Docker) in OpenStack.
> 
> Thanks Russell for giving some early feedback.
> 
> Also, Krishna Raman from RedHat already gave a first shot at drafting
> the Rest API:
> 
> https://etherpad.openstack.org/p/containers-service-api
> 
> 
> Sam
> 
> -- 
> @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