Open Stack

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:huyanyan84 at 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.lu at huawei.com
> <mailto: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://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev