[openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes

Qiming Teng tengqim at linux.vnet.ibm.com
Mon May 16 01:07:57 UTC 2016


On Sun, May 15, 2016 at 10:49:39PM +0000, Hongbin Lu wrote:
> 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

Seriously, I'm suggesting Magnum to use Senlin for this task. Senlin has
an API that provides rich operations you will need to manage a cluster
of things, where the "thing" here can be a Heat stack or a Nova server.

A "thing" is modeled as a Profile in Senlin, so it is pretty easy and
straightforward for Magnum to feed in the HOT templates (possibly with
parameters and environments?) to Senlin and offload the group management
task from Magnum.

Speaking of cross-AZ placement, Senlin has a policy plugin for this
purpose already. Regarding bay nodes bearing different set of flavors,
Senlin also permits that.

I believe by offloading these operations to Senlin, Magnum can remain
focusing on getting COE management and get it done well. I also believe
that Senlin team will be very responsive to your requirements if there
are needs to tune the Senlin API/policy/mechanism.

Regards,
  Qiming




More information about the OpenStack-dev mailing list