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

Hongbin Lu hongbin.lu at huawei.com
Tue May 17 02:49:29 UTC 2016


I have an opposing point of view. In summary of below, there are actually three kinds of style.

1. The “python-*client” style. For example:
$ magnum node-add [--flavor <flavor-id>] <bay>

2. The OSC style. For example:
$ openstack bay node add [--flavor <flavor-id>]

3. The proposed style (which is a mix of #1 and #2). For example:
$ magnum bay node add [--flavor <flavor-id>]

My observation is that all OpenStack projects are following both #1 and #2. I just couldn't find any OpenStack project that implements #3. If Magnum implements #3, we immediately become an outlier. I understand the intention is to make the python-client -> OSC migration easier, but the consequence might be more confusion than the original migration plan. Therefore, I would vote against #3.

Best regards,
Hongbin

From: Ton Ngo [mailto:ton at us.ibm.com]
Sent: May-16-16 7:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes


I would vote for the OSC pattern to make it easier for the users, since we already expect that migration path.
Also agree with Tom that this is a significant change so we should write a spec to think through carefully.
Ton,

[Inactive hide details for Adrian Otto ---05/16/2016 11:24:33 AM---> On May 16, 2016, at 7:59 AM, Steven Dake (stdake) <stdake at c]Adrian Otto ---05/16/2016 11:24:33 AM---> On May 16, 2016, at 7:59 AM, Steven Dake (stdake) <stdake at cisco.com<mailto:stdake at cisco.com>> wrote: >

From: Adrian Otto <adrian.otto at rackspace.com<mailto:adrian.otto at rackspace.com>>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: 05/16/2016 11:24 AM
Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes

________________________________




> On May 16, 2016, at 7:59 AM, Steven Dake (stdake) <stdake at cisco.com<mailto:stdake at cisco.com>> wrote:
>
> 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>?

The more common pattern is actually:

<verb> <options> <object>

or:

<verb> <object> <options>

Examples:

# trove resize-instance <instance-id> <flavor-id>
# nova reboot --hard <instance-id>

The OSC tool uses:

<object-name> <verb> <options> <object>

Example:

# openstack server reboot [-h] [--hard | --soft] [--wait] <server>

If we wanted to be consistent with the original Openstack style, the proposal would be something like:

magnum reset [--hard] <bay>
magnum rebuild <bay>
magnum node-delete <bay>
magnum node-add [--flavor <flavor-id>] <bay>
magnum node-reset <bay> <name/uuid>
magnum node-list <bay>

If we wanted to model after OSC, it would be:

magnum bay reset [--hard] <bay>
magnum bay rebuild <bay>
magnum bay node delete <bay>
magnum bay node add [--flavor <flavor-id>] <bay>
magnum bay node reset <bay> <name/uuid>
magnum bay node list <bay>

This one is my preference, because when integrated with OSC, the user does not need to change the command arguments, just swap in “openstack” for “magnum”. The actual order of placement for named options does not matter.

Adrian

>
> 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<mailto: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<mailto:yuanying at oeilvert.org>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/20160517/24718a90/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160517/24718a90/attachment.gif>


More information about the OpenStack-dev mailing list