Re: [openstack-dev] [Higgins][Zun] Project roadmap
Welcome! Please feel free to ping us in IRC (#openstack-zun) or join our weekly meeting (https://wiki.openstack.org/wiki/Zun#Meetings). I am happy to discuss how to collaborate further. Best regards, Hongbin From: Pengfei Ni [mailto:feisk...@gmail.com] Sent: June-16-16 6:36 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Qi Ming Teng; yanya...@cn.ibm.com; flw...@catalyst.net.nz; adit...@nectechnologies.in; sitlani.namr...@yahoo.in; Chandan Kumar; Sheel Rana Insaan; Yuanying Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap Hello, everyone, Hypernetes has done some work same as this project, that is - Leverate Neutron for container network - Leverate Cinder for storage - Leverate Keystone for auth - Leverate HyperContainer for hypervisor-based container runtime We could help to provide hypervisor-based container runtime (HyperContainer) integration for Zun. See https://github.com/hyperhq/hypernetes and http://blog.kubernetes.io/2016/05/hypernetes-security-and-multi-tenancy-in-kubernetes.html for more information about Hypernetes, and see https://github.com/hyperhq/hyperd for more information about HyperContainer. Best regards. --- Pengfei Ni Software Engineer @Hyper 2016-06-13 6:10 GMT+08:00 Hongbin Lu mailto:hongbin...@huawei.com>>: Hi team, During the team meetings these weeks, we collaborated the initial project roadmap. I summarized it as below. Please review. * Implement a common container abstraction for different container runtimes. The initial implementation will focus on supporting basic container operations (i.e. CRUD). * Focus on non-nested containers use cases (running containers on physical hosts), and revisit nested containers use cases (running containers on VMs) later. * Provide two set of APIs to access containers: The Nova APIs and the Zun-native APIs. In particular, the Zun-native APIs will expose full container capabilities, and Nova APIs will expose capabilities that are shared between containers and VMs. * Leverage Neutron (via Kuryr) for container networking. * Leverage Cinder for container data volume. * Leverage Glance for storing container images. If necessary, contribute to Glance for missing features (i.e. support layer of container images). * Support enforcing multi-tenancy by doing the following: ** Add configurable options for scheduler to enforce neighboring containers belonging to the same tenant. ** Support hypervisor-based container runtimes. The following topics have been discussed, but the team cannot reach consensus on including them into the short-term project scope. We skipped them for now and might revisit them later. * Support proxying API calls to COEs. * Advanced container operations (i.e. keep container alive, load balancer setup, rolling upgrade). * Nested containers use cases (i.e. provision container hosts). * Container composition (i.e. support docker-compose like DSL). NOTE: I might forgot and mis-understood something. Please feel free to point out if anything is wrong or missing. Best regards, Hongbin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Higgins][Zun] Project roadmap
Hello, everyone, Hypernetes has done some work same as this project, that is - Leverate Neutron for container network - Leverate Cinder for storage - Leverate Keystone for auth - Leverate HyperContainer for hypervisor-based container runtime We could help to provide hypervisor-based container runtime (HyperContainer) integration for Zun. See https://github.com/hyperhq/hypernetes and http://blog.kubernetes.io/2016/05/hypernetes-security-and-multi-tenancy-in-kubernetes.html for more information about Hypernetes, and see https://github.com/hyperhq/hyperd for more information about HyperContainer. Best regards. --- Pengfei Ni Software Engineer @Hyper 2016-06-13 6:10 GMT+08:00 Hongbin Lu : > Hi team, > > > > During the team meetings these weeks, we collaborated the initial project > roadmap. I summarized it as below. Please review. > > > > * Implement a common container abstraction for different container > runtimes. The initial implementation will focus on supporting basic > container operations (i.e. CRUD). > > * Focus on non-nested containers use cases (running containers on physical > hosts), and revisit nested containers use cases (running containers on VMs) > later. > > * Provide two set of APIs to access containers: The Nova APIs and the > Zun-native APIs. In particular, the Zun-native APIs will expose full > container capabilities, and Nova APIs will expose capabilities that are > shared between containers and VMs. > > * Leverage Neutron (via Kuryr) for container networking. > > * Leverage Cinder for container data volume. > > * Leverage Glance for storing container images. If necessary, contribute > to Glance for missing features (i.e. support layer of container images). > > * Support enforcing multi-tenancy by doing the following: > > ** Add configurable options for scheduler to enforce neighboring > containers belonging to the same tenant. > > ** Support hypervisor-based container runtimes. > > > > The following topics have been discussed, but the team cannot reach > consensus on including them into the short-term project scope. We skipped > them for now and might revisit them later. > > * Support proxying API calls to COEs. > > * Advanced container operations (i.e. keep container alive, load balancer > setup, rolling upgrade). > > * Nested containers use cases (i.e. provision container hosts). > > * Container composition (i.e. support docker-compose like DSL). > > > > NOTE: I might forgot and mis-understood something. Please feel free to > point out if anything is wrong or missing. > > > > Best regards, > > Hongbin > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Higgins][Zun] Project roadmap
> -Original Message- > From: Flavio Percoco [mailto:fla...@redhat.com] > Sent: June-14-16 3:44 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap > > On 13/06/16 18:46 +, Hongbin Lu wrote: > > > > > >> -Original Message- > >> From: Sudipto Biswas [mailto:sbisw...@linux.vnet.ibm.com] > >> Sent: June-13-16 1:43 PM > >> To: openstack-dev@lists.openstack.org > >> Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap > >> > >> > >> > >> On Monday 13 June 2016 06:57 PM, Flavio Percoco wrote: > >> > On 12/06/16 22:10 +, Hongbin Lu wrote: > >> >> Hi team, > >> >> > >> >> During the team meetings these weeks, we collaborated the initial > >> >> project roadmap. I summarized it as below. Please review. > >> >> > >> >> * Implement a common container abstraction for different > container > >> >> runtimes. The initial implementation will focus on supporting > >> >> basic container operations (i.e. CRUD). > >> > > >> > What COE's are being considered for the first implementation? Just > >> > docker and kubernetes? > >[Hongbin Lu] Container runtimes, docker in particular, are being > considered for the first implementation. We discussed how to support > COEs in Zun but cannot reach an agreement on the direction. I will > leave it for further discussion. > > > >> > > >> >> * Focus on non-nested containers use cases (running containers on > >> >> physical hosts), and revisit nested containers use cases (running > >> >> containers on VMs) later. > >> >> * Provide two set of APIs to access containers: The Nova APIs and > >> the > >> >> Zun-native APIs. In particular, the Zun-native APIs will expose > >> >> full container capabilities, and Nova APIs will expose > >> >> capabilities that are shared between containers and VMs. > >> > > >> > - Is the nova side going to be implemented in the form of a Nova > >> > driver (like ironic's?)? What do you mean by APIs here? > >[Hongbin Lu] Yes, the plan is to implement a Zun virt-driver for Nova. > The idea is similar to Ironic. > > > >> > > >> > - What operations are we expecting this to support (just CRUD > >> > operations on containers?)? > >[Hongbin Lu] We are working on finding the list of operations to > support. There is a BP for tracking this effort: > https://blueprints.launchpad.net/zun/+spec/api-design . > > > >> > > >> > I can see this driver being useful for specialized services like > >> Trove > >> > but I'm curious/concerned about how this will be used by end users > >> > (assuming that's the goal). > >[Hongbin Lu] I agree that end users might not be satisfied by basic > container operations like CRUD. We will discuss how to offer more to > make the service to be useful in production. > > I'd probably leave this out for now but this is just my opinion. > Personally, I think users, if presented with both APIs - nova's and > Zun's - they'll prefer Zun's. > > Specifically, you don't interact with a container the same way you > interact with a VM (but I'm sure you know all these way better than me). > I guess my concern is that I don't see too much value in this other > than allowing specialized services to run containers through Nova. ACK > > > >> > > >> > > >> >> * Leverage Neutron (via Kuryr) for container networking. > >> >> * Leverage Cinder for container data volume. > >> >> * Leverage Glance for storing container images. If necessary, > >> >> contribute to Glance for missing features (i.e. support layer of > >> >> container images). > >> > > >> > Are you aware of https://review.openstack.org/#/c/249282/ ? > >> This support is very minimalistic in nature, since it doesn't do > >> anything beyond just storing a docker FS tar ball. > >> I think it was felt that, further support for docker FS was needed. > >> While there were suggestions of private docker registry, having > >> something in band (w.r.t openstack) maybe desirable. > >[Hongbin Lu] Yes, Glance doesn't support layer of container images > which is a missing feature. > > Yup, I didn't mean to imply that would d
Re: [openstack-dev] [Higgins][Zun] Project roadmap
I think there's a weird cycle in plugging into nova too... Say the cloud has no native container support added except for Zun. The container api Zun provides could be mapped to a Zun plugin that: 1. nova boot --image centos --user-data 'yum install -y docker; yum start docker; ' 2. starts the container that was requested on that docker supporting vm. So if you add a flavor to nova to map to a container, and you accept a flavor to Zun to launch containers on, you have to know to filter out the flavors that might come right back to Zun so you don't get into an infinite loop of nested docker instances. Thanks, Kevin From: Flavio Percoco [fla...@redhat.com] Sent: Tuesday, June 14, 2016 12:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap On 13/06/16 18:46 +, Hongbin Lu wrote: > > >> -Original Message- >> From: Sudipto Biswas [mailto:sbisw...@linux.vnet.ibm.com] >> Sent: June-13-16 1:43 PM >> To: openstack-dev@lists.openstack.org >> Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap >> >> >> >> On Monday 13 June 2016 06:57 PM, Flavio Percoco wrote: >> > On 12/06/16 22:10 +, Hongbin Lu wrote: >> >> Hi team, >> >> >> >> During the team meetings these weeks, we collaborated the initial >> >> project roadmap. I summarized it as below. Please review. >> >> >> >> * Implement a common container abstraction for different container >> >> runtimes. The initial implementation will focus on supporting basic >> >> container operations (i.e. CRUD). >> > >> > What COE's are being considered for the first implementation? Just >> > docker and kubernetes? >[Hongbin Lu] Container runtimes, docker in particular, are being considered >for the first implementation. We discussed how to support COEs in Zun but >cannot reach an agreement on the direction. I will leave it for further >discussion. > >> > >> >> * Focus on non-nested containers use cases (running containers on >> >> physical hosts), and revisit nested containers use cases (running >> >> containers on VMs) later. >> >> * Provide two set of APIs to access containers: The Nova APIs and >> the >> >> Zun-native APIs. In particular, the Zun-native APIs will expose full >> >> container capabilities, and Nova APIs will expose capabilities that >> >> are shared between containers and VMs. >> > >> > - Is the nova side going to be implemented in the form of a Nova >> > driver (like ironic's?)? What do you mean by APIs here? >[Hongbin Lu] Yes, the plan is to implement a Zun virt-driver for Nova. The >idea is similar to Ironic. > >> > >> > - What operations are we expecting this to support (just CRUD >> > operations on containers?)? >[Hongbin Lu] We are working on finding the list of operations to support. >There is a BP for tracking this effort: >https://blueprints.launchpad.net/zun/+spec/api-design . > >> > >> > I can see this driver being useful for specialized services like >> Trove >> > but I'm curious/concerned about how this will be used by end users >> > (assuming that's the goal). >[Hongbin Lu] I agree that end users might not be satisfied by basic container >operations like CRUD. We will discuss how to offer more to make the service to >be useful in production. I'd probably leave this out for now but this is just my opinion. Personally, I think users, if presented with both APIs - nova's and Zun's - they'll prefer Zun's. Specifically, you don't interact with a container the same way you interact with a VM (but I'm sure you know all these way better than me). I guess my concern is that I don't see too much value in this other than allowing specialized services to run containers through Nova. >> > >> > >> >> * Leverage Neutron (via Kuryr) for container networking. >> >> * Leverage Cinder for container data volume. >> >> * Leverage Glance for storing container images. If necessary, >> >> contribute to Glance for missing features (i.e. support layer of >> >> container images). >> > >> > Are you aware of https://review.openstack.org/#/c/249282/ ? >> This support is very minimalistic in nature, since it doesn't do >> anything beyond just storing a docker FS tar ball. >> I think it was felt that, further support for docker FS was needed. >> While there were suggestions of private doc
Re: [openstack-dev] [Higgins][Zun] Project roadmap
Hi all, it looks like Glare may cover some (or all) your use cases. To understand the functionality proposed to Glare I suggest you to read this: https://review.openstack.org/#/c/283136/. It would be cool if Glare supports everything you need. If you need something else please add a comment, we will try to consider your requirements. You can also contact me(kairat), Mike Fedosin (mfedosin) and Nikhil Komawar (nikhil) for any questions related to Glare. Best regards, Kairat Kushaev On Tue, Jun 14, 2016 at 10:43 AM, Flavio Percoco wrote: > On 13/06/16 18:46 +, Hongbin Lu wrote: > >> >> >> -Original Message- >>> From: Sudipto Biswas [mailto:sbisw...@linux.vnet.ibm.com] >>> Sent: June-13-16 1:43 PM >>> To: openstack-dev@lists.openstack.org >>> Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap >>> >>> >>> >>> On Monday 13 June 2016 06:57 PM, Flavio Percoco wrote: >>> > On 12/06/16 22:10 +, Hongbin Lu wrote: >>> >> Hi team, >>> >> >>> >> During the team meetings these weeks, we collaborated the initial >>> >> project roadmap. I summarized it as below. Please review. >>> >> >>> >> * Implement a common container abstraction for different container >>> >> runtimes. The initial implementation will focus on supporting basic >>> >> container operations (i.e. CRUD). >>> > >>> > What COE's are being considered for the first implementation? Just >>> > docker and kubernetes? >>> >> [Hongbin Lu] Container runtimes, docker in particular, are being >> considered for the first implementation. We discussed how to support COEs >> in Zun but cannot reach an agreement on the direction. I will leave it for >> further discussion. >> >> > >>> >> * Focus on non-nested containers use cases (running containers on >>> >> physical hosts), and revisit nested containers use cases (running >>> >> containers on VMs) later. >>> >> * Provide two set of APIs to access containers: The Nova APIs and >>> the >>> >> Zun-native APIs. In particular, the Zun-native APIs will expose full >>> >> container capabilities, and Nova APIs will expose capabilities that >>> >> are shared between containers and VMs. >>> > >>> > - Is the nova side going to be implemented in the form of a Nova >>> > driver (like ironic's?)? What do you mean by APIs here? >>> >> [Hongbin Lu] Yes, the plan is to implement a Zun virt-driver for Nova. >> The idea is similar to Ironic. >> >> > >>> > - What operations are we expecting this to support (just CRUD >>> > operations on containers?)? >>> >> [Hongbin Lu] We are working on finding the list of operations to support. >> There is a BP for tracking this effort: >> https://blueprints.launchpad.net/zun/+spec/api-design . >> >> > >>> > I can see this driver being useful for specialized services like >>> Trove >>> > but I'm curious/concerned about how this will be used by end users >>> > (assuming that's the goal). >>> >> [Hongbin Lu] I agree that end users might not be satisfied by basic >> container operations like CRUD. We will discuss how to offer more to make >> the service to be useful in production. >> > > I'd probably leave this out for now but this is just my opinion. > Personally, I > think users, if presented with both APIs - nova's and Zun's - they'll > prefer > Zun's. > > Specifically, you don't interact with a container the same way you > interact with > a VM (but I'm sure you know all these way better than me). I guess my > concern is > that I don't see too much value in this other than allowing specialized > services > to run containers through Nova. > > > > >>> > >>> >> * Leverage Neutron (via Kuryr) for container networking. >>> >> * Leverage Cinder for container data volume. >>> >> * Leverage Glance for storing container images. If necessary, >>> >> contribute to Glance for missing features (i.e. support layer of >>> >> container images). >>> > >>> > Are you aware of https://review.openstack.org/#/c/249282/ ? >>> This support is very minimalistic in nature, since it doesn't do >>> anything beyond just storing a docker FS tar ball. >>> I think it was felt that, further support for docker FS was needed. &
Re: [openstack-dev] [Higgins][Zun] Project roadmap
On 13/06/16 18:46 +, Hongbin Lu wrote: -Original Message- From: Sudipto Biswas [mailto:sbisw...@linux.vnet.ibm.com] Sent: June-13-16 1:43 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap On Monday 13 June 2016 06:57 PM, Flavio Percoco wrote: > On 12/06/16 22:10 +, Hongbin Lu wrote: >> Hi team, >> >> During the team meetings these weeks, we collaborated the initial >> project roadmap. I summarized it as below. Please review. >> >> * Implement a common container abstraction for different container >> runtimes. The initial implementation will focus on supporting basic >> container operations (i.e. CRUD). > > What COE's are being considered for the first implementation? Just > docker and kubernetes? [Hongbin Lu] Container runtimes, docker in particular, are being considered for the first implementation. We discussed how to support COEs in Zun but cannot reach an agreement on the direction. I will leave it for further discussion. > >> * Focus on non-nested containers use cases (running containers on >> physical hosts), and revisit nested containers use cases (running >> containers on VMs) later. >> * Provide two set of APIs to access containers: The Nova APIs and the >> Zun-native APIs. In particular, the Zun-native APIs will expose full >> container capabilities, and Nova APIs will expose capabilities that >> are shared between containers and VMs. > > - Is the nova side going to be implemented in the form of a Nova > driver (like ironic's?)? What do you mean by APIs here? [Hongbin Lu] Yes, the plan is to implement a Zun virt-driver for Nova. The idea is similar to Ironic. > > - What operations are we expecting this to support (just CRUD > operations on containers?)? [Hongbin Lu] We are working on finding the list of operations to support. There is a BP for tracking this effort: https://blueprints.launchpad.net/zun/+spec/api-design . > > I can see this driver being useful for specialized services like Trove > but I'm curious/concerned about how this will be used by end users > (assuming that's the goal). [Hongbin Lu] I agree that end users might not be satisfied by basic container operations like CRUD. We will discuss how to offer more to make the service to be useful in production. I'd probably leave this out for now but this is just my opinion. Personally, I think users, if presented with both APIs - nova's and Zun's - they'll prefer Zun's. Specifically, you don't interact with a container the same way you interact with a VM (but I'm sure you know all these way better than me). I guess my concern is that I don't see too much value in this other than allowing specialized services to run containers through Nova. > > >> * Leverage Neutron (via Kuryr) for container networking. >> * Leverage Cinder for container data volume. >> * Leverage Glance for storing container images. If necessary, >> contribute to Glance for missing features (i.e. support layer of >> container images). > > Are you aware of https://review.openstack.org/#/c/249282/ ? This support is very minimalistic in nature, since it doesn't do anything beyond just storing a docker FS tar ball. I think it was felt that, further support for docker FS was needed. While there were suggestions of private docker registry, having something in band (w.r.t openstack) maybe desirable. [Hongbin Lu] Yes, Glance doesn't support layer of container images which is a missing feature. Yup, I didn't mean to imply that would do it all for you rather that there's been some progress there. As far as layered containers goes, you might want to look into Glare. Flavio >> * Support enforcing multi-tenancy by doing the following: >> ** Add configurable options for scheduler to enforce neighboring >> containers belonging to the same tenant. >> ** Support hypervisor-based container runtimes. >> >> The following topics have been discussed, but the team cannot reach >> consensus on including them into the short-term project scope. We >> skipped them for now and might revisit them later. >> * Support proxying API calls to COEs. > > Any link to what this proxy will do and what service it'll talk to? > I'd generally advice against having proxy calls in services. We've > just done work in Nova to deprecate the Nova Image proxy. [Hongbin Lu] Maybe "proxy" is not the right word. What I mean is to translate the request to API calls of COEs. For example, users request to create a container in Zun, then Zun creates a single-container pod in k8s. > >> * Advanced container operations (i.e. keep container alive, load >> ba
Re: [openstack-dev] [Higgins][Zun] Project roadmap
> -Original Message- > From: Sudipto Biswas [mailto:sbisw...@linux.vnet.ibm.com] > Sent: June-13-16 1:43 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap > > > > On Monday 13 June 2016 06:57 PM, Flavio Percoco wrote: > > On 12/06/16 22:10 +, Hongbin Lu wrote: > >> Hi team, > >> > >> During the team meetings these weeks, we collaborated the initial > >> project roadmap. I summarized it as below. Please review. > >> > >> * Implement a common container abstraction for different container > >> runtimes. The initial implementation will focus on supporting basic > >> container operations (i.e. CRUD). > > > > What COE's are being considered for the first implementation? Just > > docker and kubernetes? [Hongbin Lu] Container runtimes, docker in particular, are being considered for the first implementation. We discussed how to support COEs in Zun but cannot reach an agreement on the direction. I will leave it for further discussion. > > > >> * Focus on non-nested containers use cases (running containers on > >> physical hosts), and revisit nested containers use cases (running > >> containers on VMs) later. > >> * Provide two set of APIs to access containers: The Nova APIs and > the > >> Zun-native APIs. In particular, the Zun-native APIs will expose full > >> container capabilities, and Nova APIs will expose capabilities that > >> are shared between containers and VMs. > > > > - Is the nova side going to be implemented in the form of a Nova > > driver (like ironic's?)? What do you mean by APIs here? [Hongbin Lu] Yes, the plan is to implement a Zun virt-driver for Nova. The idea is similar to Ironic. > > > > - What operations are we expecting this to support (just CRUD > > operations on containers?)? [Hongbin Lu] We are working on finding the list of operations to support. There is a BP for tracking this effort: https://blueprints.launchpad.net/zun/+spec/api-design . > > > > I can see this driver being useful for specialized services like > Trove > > but I'm curious/concerned about how this will be used by end users > > (assuming that's the goal). [Hongbin Lu] I agree that end users might not be satisfied by basic container operations like CRUD. We will discuss how to offer more to make the service to be useful in production. > > > > > >> * Leverage Neutron (via Kuryr) for container networking. > >> * Leverage Cinder for container data volume. > >> * Leverage Glance for storing container images. If necessary, > >> contribute to Glance for missing features (i.e. support layer of > >> container images). > > > > Are you aware of https://review.openstack.org/#/c/249282/ ? > This support is very minimalistic in nature, since it doesn't do > anything beyond just storing a docker FS tar ball. > I think it was felt that, further support for docker FS was needed. > While there were suggestions of private docker registry, having > something in band (w.r.t openstack) maybe desirable. [Hongbin Lu] Yes, Glance doesn't support layer of container images which is a missing feature. > >> * Support enforcing multi-tenancy by doing the following: > >> ** Add configurable options for scheduler to enforce neighboring > >> containers belonging to the same tenant. > >> ** Support hypervisor-based container runtimes. > >> > >> The following topics have been discussed, but the team cannot reach > >> consensus on including them into the short-term project scope. We > >> skipped them for now and might revisit them later. > >> * Support proxying API calls to COEs. > > > > Any link to what this proxy will do and what service it'll talk to? > > I'd generally advice against having proxy calls in services. We've > > just done work in Nova to deprecate the Nova Image proxy. [Hongbin Lu] Maybe "proxy" is not the right word. What I mean is to translate the request to API calls of COEs. For example, users request to create a container in Zun, then Zun creates a single-container pod in k8s. > > > >> * Advanced container operations (i.e. keep container alive, load > >> balancer setup, rolling upgrade). > >> * Nested containers use cases (i.e. provision container hosts). > >> * Container composition (i.e. support docker-compose like DSL). > >> > >> NOTE: I might forgot and mis-understood something. Please feel free > >> to point out if anything is wrong or missing. > > > > It sounds yo
Re: [openstack-dev] [Higgins][Zun] Project roadmap
From: Antoni Segura Puimedon [mailto:toni+openstac...@midokura.com] Sent: June-13-16 3:22 AM To: OpenStack Development Mailing List (not for usage questions) Cc: yanya...@cn.ibm.com; Qi Ming Teng; adit...@nectechnologies.in; sitlani.namr...@yahoo.in; flw...@catalyst.net.nz; Chandan Kumar; Sheel Rana Insaan; Yuanying Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap On Mon, Jun 13, 2016 at 12:10 AM, Hongbin Lu mailto:hongbin...@huawei.com>> wrote: Hi team, During the team meetings these weeks, we collaborated the initial project roadmap. I summarized it as below. Please review. * Implement a common container abstraction for different container runtimes. The initial implementation will focus on supporting basic container operations (i.e. CRUD). * Focus on non-nested containers use cases (running containers on physical hosts), and revisit nested containers use cases (running containers on VMs) later. * Provide two set of APIs to access containers: The Nova APIs and the Zun-native APIs. In particular, the Zun-native APIs will expose full container capabilities, and Nova APIs will expose capabilities that are shared between containers and VMs. * Leverage Neutron (via Kuryr) for container networking. Great! Let us know anytime we can help * Leverage Cinder for container data volume. Have you considered fuxi? https://github.com/openstack/fuxi [Hongbin Lu] We discussed if we should leverage Kuryr/Fuxi for storage, but we are unclear what this project offer exactly and how it works. The maturity of the project is also a concern, but we will revisit it later. * Leverage Glance for storing container images. If necessary, contribute to Glance for missing features (i.e. support layer of container images). * Support enforcing multi-tenancy by doing the following: ** Add configurable options for scheduler to enforce neighboring containers belonging to the same tenant. What about have the scheduler pluggable instead of having a lot of configuration options? [Hongbin Lu] For short-term, no. We will implement a very simple scheduler to start. For long-term, we will wait for the scheduler-as-a-service project: https://wiki.openstack.org/wiki/Gantt . I believe Gantt will have a pluggable architecture so that your requirement will be satisfied. If not, we will revisit it. ** Support hypervisor-based container runtimes. Is that hyper.sh? [Hongbin Lu] It could be, or Clear Container, or something similar. The following topics have been discussed, but the team cannot reach consensus on including them into the short-term project scope. We skipped them for now and might revisit them later. * Support proxying API calls to COEs. * Advanced container operations (i.e. keep container alive, load balancer setup, rolling upgrade). * Nested containers use cases (i.e. provision container hosts). * Container composition (i.e. support docker-compose like DSL). Will it have ordering primitives, i.e. this container won't start until this one is up and running. ? I also wonder whether the Higgins container abstraction will have rich status reporting that can be used in ordering. For example, whether it can differentiate started containers from those that are already listening in their exposed ports. [Hongbin Lu] I am open to that, but needs to discuss the idea further. NOTE: I might forgot and mis-understood something. Please feel free to point out if anything is wrong or missing. Best regards, Hongbin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Higgins][Zun] Project roadmap
On Monday 13 June 2016 06:57 PM, Flavio Percoco wrote: On 12/06/16 22:10 +, Hongbin Lu wrote: Hi team, During the team meetings these weeks, we collaborated the initial project roadmap. I summarized it as below. Please review. * Implement a common container abstraction for different container runtimes. The initial implementation will focus on supporting basic container operations (i.e. CRUD). What COE's are being considered for the first implementation? Just docker and kubernetes? * Focus on non-nested containers use cases (running containers on physical hosts), and revisit nested containers use cases (running containers on VMs) later. * Provide two set of APIs to access containers: The Nova APIs and the Zun-native APIs. In particular, the Zun-native APIs will expose full container capabilities, and Nova APIs will expose capabilities that are shared between containers and VMs. - Is the nova side going to be implemented in the form of a Nova driver (like ironic's?)? What do you mean by APIs here? - What operations are we expecting this to support (just CRUD operations on containers?)? I can see this driver being useful for specialized services like Trove but I'm curious/concerned about how this will be used by end users (assuming that's the goal). * Leverage Neutron (via Kuryr) for container networking. * Leverage Cinder for container data volume. * Leverage Glance for storing container images. If necessary, contribute to Glance for missing features (i.e. support layer of container images). Are you aware of https://review.openstack.org/#/c/249282/ ? This support is very minimalistic in nature, since it doesn't do anything beyond just storing a docker FS tar ball. I think it was felt that, further support for docker FS was needed. While there were suggestions of private docker registry, having something in band (w.r.t openstack) maybe desirable. * Support enforcing multi-tenancy by doing the following: ** Add configurable options for scheduler to enforce neighboring containers belonging to the same tenant. ** Support hypervisor-based container runtimes. The following topics have been discussed, but the team cannot reach consensus on including them into the short-term project scope. We skipped them for now and might revisit them later. * Support proxying API calls to COEs. Any link to what this proxy will do and what service it'll talk to? I'd generally advice against having proxy calls in services. We've just done work in Nova to deprecate the Nova Image proxy. * Advanced container operations (i.e. keep container alive, load balancer setup, rolling upgrade). * Nested containers use cases (i.e. provision container hosts). * Container composition (i.e. support docker-compose like DSL). NOTE: I might forgot and mis-understood something. Please feel free to point out if anything is wrong or missing. It sounds you've got more than enough to work on for now, I think it's fine to table these topics for now. just my $0.02 Flavio __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Higgins][Zun] Project roadmap
On 12/06/16 22:10 +, Hongbin Lu wrote: Hi team, During the team meetings these weeks, we collaborated the initial project roadmap. I summarized it as below. Please review. * Implement a common container abstraction for different container runtimes. The initial implementation will focus on supporting basic container operations (i.e. CRUD). What COE's are being considered for the first implementation? Just docker and kubernetes? * Focus on non-nested containers use cases (running containers on physical hosts), and revisit nested containers use cases (running containers on VMs) later. * Provide two set of APIs to access containers: The Nova APIs and the Zun-native APIs. In particular, the Zun-native APIs will expose full container capabilities, and Nova APIs will expose capabilities that are shared between containers and VMs. - Is the nova side going to be implemented in the form of a Nova driver (like ironic's?)? What do you mean by APIs here? - What operations are we expecting this to support (just CRUD operations on containers?)? I can see this driver being useful for specialized services like Trove but I'm curious/concerned about how this will be used by end users (assuming that's the goal). * Leverage Neutron (via Kuryr) for container networking. * Leverage Cinder for container data volume. * Leverage Glance for storing container images. If necessary, contribute to Glance for missing features (i.e. support layer of container images). Are you aware of https://review.openstack.org/#/c/249282/ ? * Support enforcing multi-tenancy by doing the following: ** Add configurable options for scheduler to enforce neighboring containers belonging to the same tenant. ** Support hypervisor-based container runtimes. The following topics have been discussed, but the team cannot reach consensus on including them into the short-term project scope. We skipped them for now and might revisit them later. * Support proxying API calls to COEs. Any link to what this proxy will do and what service it'll talk to? I'd generally advice against having proxy calls in services. We've just done work in Nova to deprecate the Nova Image proxy. * Advanced container operations (i.e. keep container alive, load balancer setup, rolling upgrade). * Nested containers use cases (i.e. provision container hosts). * Container composition (i.e. support docker-compose like DSL). NOTE: I might forgot and mis-understood something. Please feel free to point out if anything is wrong or missing. It sounds you've got more than enough to work on for now, I think it's fine to table these topics for now. just my $0.02 Flavio -- @flaper87 Flavio Percoco signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Higgins][Zun] Project roadmap
On Mon, Jun 13, 2016 at 12:10 AM, Hongbin Lu wrote: > Hi team, > > > > During the team meetings these weeks, we collaborated the initial project > roadmap. I summarized it as below. Please review. > > > > * Implement a common container abstraction for different container > runtimes. The initial implementation will focus on supporting basic > container operations (i.e. CRUD). > > * Focus on non-nested containers use cases (running containers on physical > hosts), and revisit nested containers use cases (running containers on VMs) > later. > > * Provide two set of APIs to access containers: The Nova APIs and the > Zun-native APIs. In particular, the Zun-native APIs will expose full > container capabilities, and Nova APIs will expose capabilities that are > shared between containers and VMs. > > * Leverage Neutron (via Kuryr) for container networking. > Great! Let us know anytime we can help > * Leverage Cinder for container data volume. > Have you considered fuxi? https://github.com/openstack/fuxi > * Leverage Glance for storing container images. If necessary, contribute > to Glance for missing features (i.e. support layer of container images). > > * Support enforcing multi-tenancy by doing the following: > > ** Add configurable options for scheduler to enforce neighboring > containers belonging to the same tenant. > What about have the scheduler pluggable instead of having a lot of configuration options? > ** Support hypervisor-based container runtimes. > Is that hyper.sh? > > > The following topics have been discussed, but the team cannot reach > consensus on including them into the short-term project scope. We skipped > them for now and might revisit them later. > > * Support proxying API calls to COEs. > > * Advanced container operations (i.e. keep container alive, load balancer > setup, rolling upgrade). > > * Nested containers use cases (i.e. provision container hosts). > > * Container composition (i.e. support docker-compose like DSL). > Will it have ordering primitives, i.e. this container won't start until this one is up and running. ? I also wonder whether the Higgins container abstraction will have rich status reporting that can be used in ordering. For example, whether it can differentiate started containers from those that are already listening in their exposed ports. > > > NOTE: I might forgot and mis-understood something. Please feel free to > point out if anything is wrong or missing. > > > > Best regards, > > Hongbin > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Higgins][Zun] Project roadmap
Hi team, During the team meetings these weeks, we collaborated the initial project roadmap. I summarized it as below. Please review. * Implement a common container abstraction for different container runtimes. The initial implementation will focus on supporting basic container operations (i.e. CRUD). * Focus on non-nested containers use cases (running containers on physical hosts), and revisit nested containers use cases (running containers on VMs) later. * Provide two set of APIs to access containers: The Nova APIs and the Zun-native APIs. In particular, the Zun-native APIs will expose full container capabilities, and Nova APIs will expose capabilities that are shared between containers and VMs. * Leverage Neutron (via Kuryr) for container networking. * Leverage Cinder for container data volume. * Leverage Glance for storing container images. If necessary, contribute to Glance for missing features (i.e. support layer of container images). * Support enforcing multi-tenancy by doing the following: ** Add configurable options for scheduler to enforce neighboring containers belonging to the same tenant. ** Support hypervisor-based container runtimes. The following topics have been discussed, but the team cannot reach consensus on including them into the short-term project scope. We skipped them for now and might revisit them later. * Support proxying API calls to COEs. * Advanced container operations (i.e. keep container alive, load balancer setup, rolling upgrade). * Nested containers use cases (i.e. provision container hosts). * Container composition (i.e. support docker-compose like DSL). NOTE: I might forgot and mis-understood something. Please feel free to point out if anything is wrong or missing. Best regards, Hongbin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
