Open Stack

Hi Hongbin,

I also liked the idea of having heterogeneous set of nodes but IMO such features should not be implemented in Magnum, thus deviating Magnum again from its roadmap. Whereas we should leverage Heat(or may be Senlin) APIs for the same.

I vote +1 for this feature.

Regards,
Madhuri

-----Original Message-----
From: Hongbin Lu [mailto:hongbin.lu at huawei.com] 
Sent: Thursday, June 2, 2016 3:33 AM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes

Personally, I think this is a good idea, since it can address a set of similar use cases like below:
* I want to deploy a k8s cluster to 2 availability zone (in future 2 regions/clouds).
* I want to spin up N nodes in AZ1, M nodes in AZ2.
* I want to scale the number of nodes in specific AZ/region/cloud. For example, add/remove K nodes from AZ1 (with AZ2 untouched).

The use case above should be very common and universal everywhere. To address the use case, Magnum needs to support provisioning heterogeneous set of nodes at deploy time and managing them at runtime. It looks the proposed idea (manually managing individual nodes or individual group of nodes) can address this requirement very well. Besides the proposed idea, I cannot think of an alternative solution.

Therefore, I vote to support the proposed idea.

Best regards,
Hongbin

> -----Original Message-----
> From: Hongbin Lu
> Sent: June-01-16 11:44 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [magnum] Discuss the idea of manually 
> managing the bay nodes
> 
> Hi team,
> 
> A blueprint was created for tracking this idea:
> https://blueprints.launchpad.net/magnum/+spec/manually-manage-bay-
> nodes . I won't approve the BP until there is a team decision on 
> accepting/rejecting the idea.
> 
> From the discussion in design summit, it looks everyone is OK with the 
> idea in general (with some disagreements in the API style). However, 
> from the last team meeting, it looks some people disagree with the 
> idea fundamentally. so I re-raised this ML to re-discuss.
> 
> If you agree or disagree with the idea of manually managing the Heat 
> stacks (that contains individual bay nodes), please write down your 
> arguments here. Then, we can start debating on that.
> 
> Best regards,
> Hongbin
> 
> > -----Original Message-----
> > From: Cammann, Tom [mailto:tom.cammann at hpe.com]
> > Sent: May-16-16 5:28 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually 
> > managing the bay nodes
> >
> > The discussion at the summit was very positive around this
> requirement
> > but as this change will make a large impact to Magnum it will need a 
> > spec.
> >
> > On the API of things, I was thinking a slightly more generic 
> > approach to incorporate other lifecycle operations into the same API.
> > Eg:
> > magnum bay-manage <bay> <life-cycle-op>
> >
> > magnum bay-manage <bay> reset –hard
> > magnum bay-manage <bay> rebuild
> > magnum bay-manage <bay> node-delete <name/uuid> magnum bay-manage 
> > <bay> node-add –flavor <flavor> magnum bay-manage <bay> node-reset 
> > <name> magnum bay-manage <bay> node-list
> >
> > Tom
> >
> > From: Yuanying OTSUKA <yuanying at oeilvert.org>
> > Reply-To: "OpenStack Development Mailing List (not for usage 
> > questions)" <openstack-dev at lists.openstack.org>
> > Date: Monday, 16 May 2016 at 01:07
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually 
> > managing the bay nodes
> >
> > Hi,
> >
> > I think, user also want to specify the deleting node.
> > So we should manage “node” individually.
> >
> > For example:
> > $ magnum node-create —bay …
> > $ magnum node-list —bay
> > $ magnum node-delete $NODE_UUID
> >
> > Anyway, if magnum want to manage a lifecycle of container 
> > infrastructure.
> > This feature is necessary.
> >
> > Thanks
> > -yuanying
> >
> >
> > 2016年5月16日(月) 7:50 Hongbin Lu
> > <hongbin.lu at huawei.com<mailto:hongbin.lu at huawei.com>>:
> > Hi all,
> >
> > This is a continued discussion from the design summit. For recap, 
> > Magnum manages bay nodes by using ResourceGroup from Heat. This 
> > approach works but it is infeasible to manage the heterogeneity
> across
> > bay nodes, which is a frequently demanded feature. As an example, 
> > there is a request to provision bay nodes across availability zones
> [1].
> > There is another request to provision bay nodes with different set 
> > of flavors [2]. For the request features above, ResourceGroup won’t 
> > work very well.
> >
> > The proposal is to remove the usage of ResourceGroup and manually 
> > create Heat stack for each bay nodes. For example, for creating a 
> > cluster with 2 masters and 3 minions, Magnum is going to manage 6
> Heat
> > stacks (instead of 1 big Heat stack as right now):
> > * A kube cluster stack that manages the global resources
> > * Two kube master stacks that manage the two master nodes
> > * Three kube minion stacks that manage the three minion nodes
> >
> > The proposal might require an additional API endpoint to manage 
> > nodes or a group of nodes. For example:
> > $ magnum nodegroup-create --bay XXX --flavor m1.small --count 2 -- 
> > availability-zone us-east-1 ….
> > $ magnum nodegroup-create --bay XXX --flavor m1.medium --count 3 -- 
> > availability-zone us-east-2 …
> >
> > Thoughts?
> >
> > [1] https://blueprints.launchpad.net/magnum/+spec/magnum-
> availability-
> > zones
> > [2] https://blueprints.launchpad.net/magnum/+spec/support-multiple-
> > flavor
> >
> > 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 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
__________________________________________________________________________
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