Open Stack

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,



From:	Adrian Otto <adrian.otto at rackspace.com>
To:	"OpenStack Development Mailing List (not for usage questions)"
            <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>
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> [<name/uuid>]
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> [<name/uuid>]
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> 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
>
>
__________________________________________________________________________
> 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

__________________________________________________________________________
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/5d82a861/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160516/5d82a861/attachment.gif>