[openstack-dev] [higgins] Continued discussion from the last team meeting

Yanyan Hu huyanyan84 at gmail.com
Wed May 25 03:06:20 UTC 2016

Hi, Hongbing, thanks a lot for the summary! The following is my thoughts on
those two questions left:

About container composition, it is a really useful and important feature
for enduser. But based on my understanding, user can actually achieve the
same goal by leveraging other high level OpenStack services, e.g. defining
a Heat template with Higgins container resources and app/service
(softwareconfig/softwaredeployment resources) running inside containers. In
future we can implement related functionality inside Higgins to better
support this kind of use cases natively. But in current stage, I suggest we
focus on container primitive and its basic operations.

For container host management, I agree we should expose related API
interfaces to operator(admin). Ideally, Higgins should be able to manage
all container hosts(baremetal and VM) automatically, but manual
intervention could be necessary in many pratical use cases. But I suggest
to hide these API interfaces from endusers since it's not their
responsibility to manage those hosts.


2016-05-25 4:55 GMT+08:00 Hongbin Lu <hongbin.lu at huawei.com>:

> Hi all,
> At the last team meeting, we tried to define the scope of the Higgins
> project. In general, we agreed to focus on the following features as an
> initial start:
> ·         Build a container abstraction and use docker as the first
> implementation.
> ·         Focus on basic container operations (i.e. CRUD), and leave
> advanced operations (i.e. keep container alive, rolling upgrade, etc.) to
> users or other projects/services.
> ·         Start with non-nested container use cases (e.g. containers on
> physical hosts), and revisit nested container use cases (e.g. containers on
> VMs) later.
> The items below needs further discussion so I started this ML to discuss
> it.
> 1.       Container composition: implement a docker compose like feature
> 2.       Container host management: abstract container host
> For #1, it seems we broadly agreed that this is a useful feature. The
> argument is where this feature belongs to. Some people think this feature
> belongs to other projects, such as Heat, and others think it belongs to
> Higgins so we should implement it. For #2, we were mainly debating two
> things: where the container hosts come from (provisioned by Nova or
> provided by operators); should we expose host management APIs to end-users?
> Thoughts?
> Best regards,
> Hongbin
> __________________________________________________________________________
> 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

Best regards,

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

More information about the OpenStack-dev mailing list