I agree with you and Qiming. The Higgins project should start with basic 
functionalities and revisit advanced features later.

Best regards,
Hongbin

From: Yanyan Hu [mailto:huyanya...@gmail.com]
Sent: May-24-16 11:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [higgins] Continued discussion from the last team 
meeting

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.
Thanks.

2016-05-25 4:55 GMT+08:00 Hongbin Lu 
<hongbin...@huawei.com<mailto:hongbin...@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-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



--
Best regards,

Yanyan
__________________________________________________________________________
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

Reply via email to