Re: [openstack-dev] [higgins] Continued discussion from the last team meeting

[Hongbin Lu]

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:harlo...@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: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)

Re: [openstack-dev] [higgins] Continued discussion from the last team meeting

[Joshua Harlow]

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

Re: [openstack-dev] [higgins] Continued discussion from the last team meeting

[Haiwei Xu]

Hi all,

+1 for starting with  basic functionalities and hiding 'host' from end users.

Regards,
xuhaiwei

-Original Message-
From: Hongbin Lu [mailto:hongbin...@huawei.com] 
Sent: Friday, May 27, 2016 6:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [higgins] Continued discussion from the last team 
meeting

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>:

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

Re: [openstack-dev] [higgins] Continued discussion from the last team meeting

[Hongbin Lu]

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

Re: [openstack-dev] [higgins] Continued discussion from the last team meeting

[Denis Makogon]

Hello to All.

See inline comments.

Kind regards,
Denys Makogon

2016-05-24 23:55 GMT+03:00 Hongbin Lu :

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

In Docker-compose, at this point of time i'm working to extracting core
functionality into something similar to libcompose (written on Go) but with
Python API.
I can tell that it is not that fast, so that work would take some time
(couple releases). My suggestion is to implement abstraction layer that
will consume your own implementation of compose features and once
docker-compose will be ready to be consumed then in Higgins we will switch
to it.

Another thing, it is worth considering to use TOSCA modeling (see how
Tacker is doing it) for container orchestration.


> 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?
>

Here's what i think, if we would take a look at Solum that uses swarm
cluster API endpoint that defined in its config, so for me, as for operator
it is not that useful.

As first step, we can live with that, but when you would think of multisite
OpenStack containers orchestration that case wouldn't work at all. As
proposal, i'd like to see special DB model that represents swarm cluster
entity (all necessary creds to connect to it: TLS certs, user/password,
endpoint, etc.) and provide advanced placement algorithm that would help to
define where should container lay or let users to pick concrete swarm
cluster to deploy their container.


>
>
> 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
>
>
__
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

Re: [openstack-dev] [higgins] Continued discussion from the last team meeting

[Yanyan Hu]

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 :

> 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://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

Re: [openstack-dev] [higgins] Continued discussion from the last team meeting

[Qiming Teng]

On Tue, May 24, 2016 at 08:55:28PM +, 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

[openstack-dev] [higgins] Continued discussion from the last team meeting

[Hongbin Lu]

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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev