Open Stack

Joshua,

Good point. It is optimal start off a project with a greater vision and work on getting there. However, it will take time to build consensus within the team. You are welcome to participant to build the project vision. Right now, it looks the team doesn't have consensus for the long-term scope yet, but we do have consensus on the short-term objectives. In such case, I would suggest the team to focus on the basic at current stage. At the meanwhile, we are holding weekly meeting to let everyone share their long-term vision and drive censuses on them.

Best regards,
Hongbin

> -----Original Message-----
> From: Joshua Harlow [mailto:harlowja at fastmail.com]
> Sent: May-27-16 4:46 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [higgins] Continued discussion from the
> last team meeting
> 
> 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
> 
> _______________________________________________________________________
> ___
> 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