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 <[email protected]>: > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
