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

Steven Dake (stdake) stdake at cisco.com
Mon May 16 14:59:36 UTC 2016


Tom,

Devil's advocate here.. :)

Can you offer examples of other OpenStack API services which behave in
this way with a API <verb> <object> <object-verb> <options>?

I'm struggling to think of any off the top of my head, but admittedly
don't know all the ins and outs of OpenStack ;)

Thanks
-steve


On 5/16/16, 2:28 AM, "Cammann, Tom" <tom.cammann at hpe.com> wrote:

>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://OpenS
>tack-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



More information about the OpenStack-dev mailing list