Open Stack

Madhuri,

It looks both of us agree the idea of having heterogeneous set of nodes. For the implementation, I am open to alternative (I supported the work-around idea because I cannot think of a feasible implementation by purely using Heat, unless Heat support "for" logic which is very unlikely to happen. However, if anyone can think of a pure Heat implementation, I am totally fine with that).

Best regards,
Hongbin

> -----Original Message-----
> From: Kumari, Madhuri [mailto:madhuri.kumari at intel.com]
> Sent: June-02-16 12:24 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 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
> _______________________________________________________________________
> ___
> 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