I get this idea, I just want to bring up the option that if u only start
off with a basic vision, then u basically get that as a result, vs IMHO
where u start off with a bigger/greater vision and work on getting there.
I'd personally rather work on a project that has a advanced vision vs
one that has 'just do the basics' but thats just my 2 cents...
Hongbin Lu wrote:
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
__________________________________________________________________________
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
