[openstack-dev] [Higgins][Zun] Project roadmap
Fox, Kevin M
Kevin.Fox at pnnl.gov
Tue Jun 14 15:51:17 UTC 2016
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.
From: Flavio Percoco [flavio at 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 +0000, Hongbin Lu wrote:
>> -----Original Message-----
>> From: Sudipto Biswas [mailto:sbiswas7 at linux.vnet.ibm.com]
>> Sent: June-13-16 1:43 PM
>> To: openstack-dev at 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 +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
>> >> 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
>> > 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
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
>> >> * 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
>> > fine to table these topics for now.
>> > just my $0.02
>> > Flavio
>> > ____ OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > OpenStack-dev-request at 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-
>> request at lists.openstack.org?subject:unsubscribe
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev