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

Yuanying OTSUKA yuanying at oeilvert.org
Mon May 16 00:07:24 UTC 2016


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

> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160516/29e84927/attachment.html>


More information about the OpenStack-dev mailing list