Re: [openstack-dev] Introducing the new OpenStack service for Containers
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 rconradhar...@gmail.comwrote: 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 rbry...@redhat.comwrote: On 11/22/2013 02:29 PM, Krishna Raman wrote: On Nov 22, 2013, at 10:26 AM, Eric Windisch e...@cloudscaling.com mailto:e...@cloudscaling.com wrote: On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman kra...@gmail.com mailto:kra...@gmail.com 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
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 rbry...@redhat.com wrote: On 11/22/2013 02:29 PM, Krishna Raman wrote: On Nov 22, 2013, at 10:26 AM, Eric Windisch e...@cloudscaling.com mailto:e...@cloudscaling.com wrote: On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman kra...@gmail.com mailto:kra...@gmail.com 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
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
On Thu, Nov 21, 2013 at 11:07 AM, Tim Bell tim.b...@cern.ch 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
On Thu, Nov 21, 2013 at 9:58 AM, Sam Alba sam.a...@gmail.com wrote: On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman kra...@gmail.com wrote: On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba sam.a...@gmail.com 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 chuck.sh...@canonical.com 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 kra...@gmail.com wrote: On Nov 18, 2013, at 4:30 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant
Re: [openstack-dev] Introducing the new OpenStack service for Containers
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
On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman kra...@gmail.com 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
On Nov 22, 2013, at 10:26 AM, Eric Windisch e...@cloudscaling.com wrote: On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman kra...@gmail.com 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
On 11/22/2013 02:29 PM, Krishna Raman wrote: On Nov 22, 2013, at 10:26 AM, Eric Windisch e...@cloudscaling.com mailto:e...@cloudscaling.com wrote: On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman kra...@gmail.com mailto:kra...@gmail.com 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
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 kra...@gmail.com wrote: On Nov 18, 2013, at 4:30 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. 2) Declare containers as explicitly out of scope and start a new project with its own API. That is what is being proposed here. 3) Some middle ground that is a variation of #2. Consider Ironic. The idea is that Nova's API will still be used for basic provisioning, which Nova will implement by talking to Ironic. However, there are a lot of baremetal management things that don't fit in Nova at all, and those only exist in Ironic's API. I wanted to mention this option for completeness, but I don't actually think it's the right choice here. With Ironic you have a physical resource (managed by Ironic), and then instances of an image running on these physical resources (managed by Nova). With containers, there's a similar line. You have instances of containers (managed either by Nova or the new service) running on servers (managed by Nova). I think there is a good line for separating concerns, with a container service on top of Nova. Let's ask ourselves: How much overlap is there between the current compute API and a proposed containers API? Effectively, what's the diff? How much do we expect this diff to change in the coming years? The current diff demonstrates a significant clash with the current scope of Nova. I also expect a lot of innovation around containers in the next few years, which will result in wanting to do new cool things in the API. I feel that all of this justifies a new API service to best position ourselves for the long term. +1 We need to come up with the API first before we decide if this is a new service or just something that needs to be added to Nova, How about we have all interested parties meet on IRC or conf. call
Re: [openstack-dev] Introducing the new OpenStack service for Containers
On Thu, Nov 21, 2013 at 12:58 PM, Sam Alba sam.a...@gmail.com wrote: On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman kra...@gmail.com wrote: On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba sam.a...@gmail.com 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 chuck.sh...@canonical.com 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 kra...@gmail.com wrote: On Nov 18, 2013, at 4:30 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. 2) Declare containers as explicitly out of scope and start a new project with its own API. That is what is being proposed here. 3) Some middle ground that is a variation of #2. Consider Ironic.
Re: [openstack-dev] Introducing the new OpenStack service for Containers
On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman kra...@gmail.com wrote: On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba sam.a...@gmail.com 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 chuck.sh...@canonical.com 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 kra...@gmail.com wrote: On Nov 18, 2013, at 4:30 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. 2) Declare containers as explicitly out of scope and start a new project with its own API. That is what is being proposed here. 3) Some middle ground that is a variation of #2. Consider Ironic. The idea is that Nova's API will still be used for basic provisioning, which Nova will implement by talking to Ironic. However, there are a lot of baremetal management things that don't fit in Nova at all, and
Re: [openstack-dev] Introducing the new OpenStack service for Containers
++ on Fri. 9am PST. On Thu, Nov 21, 2013 at 10:57 AM, Sam Alba sam.a...@gmail.com 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 chuck.sh...@canonical.com 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 kra...@gmail.com wrote: On Nov 18, 2013, at 4:30 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. 2) Declare containers as explicitly out of scope and start a new project with its own API. That is what is being proposed here. 3) Some middle ground that is a variation of #2. Consider Ironic. The idea is that Nova's API will still be used for basic provisioning, which Nova will implement by talking to Ironic. However, there are a lot of baremetal management things that don't fit in Nova at all, and those only exist in Ironic's API. I wanted to mention this option for completeness, but I don't actually think it's the right choice here. With Ironic you have a physical resource (managed by Ironic), and then instances of an image running on these physical resources (managed by Nova). With containers, there's a similar line. You have instances of containers (managed either by Nova or the new service) running on servers (managed by Nova). I think there is a good line for separating concerns, with a container service on top of Nova. Let's ask ourselves: How much overlap is there between the current compute API and a proposed containers API? Effectively, what's the diff? How much do we expect this diff to change in the coming years? The current diff demonstrates a significant clash with the current scope of Nova. I also expect a lot of innovation around containers in the next
Re: [openstack-dev] Introducing the new OpenStack service for Containers
On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba sam.a...@gmail.com 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 chuck.sh...@canonical.com 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 kra...@gmail.com wrote: On Nov 18, 2013, at 4:30 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. 2) Declare containers as explicitly out of scope and start a new project with its own API. That is what is being proposed here. 3) Some middle ground that is a variation of #2. Consider Ironic. The idea is that Nova's API will still be used for basic provisioning, which Nova will implement by talking to Ironic. However, there are a lot of baremetal management things that don't fit in Nova at all, and those only exist in Ironic's API. I wanted to mention this option for completeness, but I don't actually think it's the right choice here. With Ironic you have a physical resource (managed by Ironic), and then instances of an image running on these physical resources (managed by Nova). With containers, there's a similar line. You have instances of containers (managed either by Nova or the new service) running on servers (managed by Nova). I think there is a good line
Re: [openstack-dev] Introducing the new OpenStack service for Containers
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 chuck.sh...@canonical.com 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 kra...@gmail.com wrote: On Nov 18, 2013, at 4:30 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. 2) Declare containers as explicitly out of scope and start a new project with its own API. That is what is being proposed here. 3) Some middle ground that is a variation of #2. Consider Ironic. The idea is that Nova's API will still be used for basic provisioning, which Nova will implement by talking to Ironic. However, there are a lot of baremetal management things that don't fit in Nova at all, and those only exist in Ironic's API. I wanted to mention this option for completeness, but I don't actually think it's the right choice here. With Ironic you have a physical resource (managed by Ironic), and then instances of an image running on these physical resources (managed by Nova). With containers, there's a similar line. You have instances of containers (managed either by Nova or the new service) running on servers (managed by Nova). I think there is a good line for separating concerns, with a container service on top of Nova. Let's ask ourselves: How much overlap is there between the current compute API and a proposed containers API? Effectively, what's the diff? How much do we expect this diff to change in the coming years? The current diff demonstrates a significant clash with the current scope of Nova. I also expect a lot of innovation around containers in the next few years, which will result in wanting to do new cool things in the API. I feel that all of this justifies a new API service to best position ourselves for the long term. +1 We need to come up with
Re: [openstack-dev] Introducing the new OpenStack service for Containers
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
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
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
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
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 rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. 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 current scope of Nova. I also expect a lot of innovation around containers in the next few years, which will
Re: [openstack-dev] Introducing the new OpenStack service for Containers
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
On Tue, Nov 19, 2013 at 6:45 AM, Chuck Short chuck.sh...@canonical.com 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 rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. 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 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
Re: [openstack-dev] Introducing the new OpenStack service for Containers
On Tue, Nov 19, 2013 at 1:02 PM, James Bottomley james.bottom...@hansenpartnership.com 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
On Tue, 2013-11-19 at 13:46 -0500, Eric Windisch wrote: On Tue, Nov 19, 2013 at 1:02 PM, James Bottomley james.bottom...@hansenpartnership.com 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
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
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
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
[openstack-dev] Introducing the new OpenStack service for Containers
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
Re: [openstack-dev] Introducing the new OpenStack service for Containers
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 sam.a...@gmail.com 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
Re: [openstack-dev] Introducing the new OpenStack service for Containers
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 stu...@demonware.net 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 sam.a...@gmail.com 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
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 sam.a...@gmail.com 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
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
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
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
On Nov 18, 2013, at 4:30 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. 2) Declare containers as explicitly out of scope and start a new project with its own API. That is what is being proposed here. 3) Some middle ground that is a variation of #2. Consider Ironic. The idea is that Nova's API will still be used for basic provisioning, which Nova will implement by talking to Ironic. However, there are a lot of baremetal management things that don't fit in Nova at all, and those only exist in Ironic's API. I wanted to mention this option for completeness, but I don't actually think it's the right choice here. With Ironic you have a physical resource (managed by Ironic), and then instances of an image running on these physical resources (managed by Nova). With containers, there's a similar line. You have instances of containers (managed either by Nova or the new service) running on servers (managed by Nova). I think there is a good line for separating concerns, with a container service on top of Nova. Let's ask ourselves: How much overlap is there between the current compute API and a proposed containers API? Effectively, what's the diff? How much do we expect this diff to change in the coming years? The current diff demonstrates a significant clash with the current scope of Nova. I also expect a lot of innovation around containers in the next few years, which will result in wanting to do new cool things in the API. I feel that all of this justifies a new API service to best position ourselves for the long term. +1 We need to come up with the API first before we decide if this is a new service or just something that needs to be added to Nova, How about we have all interested parties meet on IRC or conf. call and discuss the suggested REST API, open questions and architecture. If you are interested please add your name to the participant list on
Re: [openstack-dev] Introducing the new OpenStack service for Containers
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
On Nov 18, 2013, at 6:05 PM, Russell Bryant rbry...@redhat.com 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
