On Tue, May 24, 2016 at 08:55:28PM +0000, Hongbin Lu wrote: > 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
No doubt this would be very useful a feature for users. However, I still suggest we keep the initial scope to a bare minimum so folks can focus on the first two jobs (container abstraction + CRUD) in this cycle and get things landed soon. We already have a lot details to figure out for the first two items. The next step (maybe early next cycle?) would be about a higher level of APIs that allow users to create some structured, declarative artifacts as inputs. > 2. Container host management: abstract container host I'm not quite aware of the requirements for end users to see or even to manage the container "hosts" (bm or vm). Just like that end users are not supposed to be aware of the compute nodes when they use Nova. For operators, the story might be quite different. They will need such tools or APIs for managing the "hosts" used. Such management jobs can be automated to some extent, but I'm somehow skeptical to full automation. At the end of the day, we need to provide some knobs for operators to do things they want because the automation tool is never ever smarter than the people using it. Just my 2 cents. - Qiming > 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
