> -----Original Message----- > From: Sudipto Biswas [mailto:sbisw...@linux.vnet.ibm.com] > Sent: June-13-16 1:43 PM > To: email@example.com > 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 +0000, 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 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 __________________________________________________________________________ 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