Open Stack

From: Antoni Segura Puimedon [mailto:toni+openstackml at midokura.com]
Sent: June-13-16 3:22 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: yanyanhu at cn.ibm.com; Qi Ming Teng; aditi.s at nectechnologies.in; sitlani.namrata at yahoo.in; flwang at 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 <hongbin.lu at huawei.com<mailto:hongbin.lu at 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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160613/b49fbf57/attachment.html>