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:t...@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@c]Adrian Otto ---05/16/2016 11:24:33 AM---> On May 16, 2016, at 7:59 AM, Steven Dake (stdake) <std...@cisco.com<mailto:std...@cisco.com>> wrote: > From: Adrian Otto <adrian.o...@rackspace.com<mailto:adrian.o...@rackspace.com>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@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) > <std...@cisco.com<mailto:std...@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.camm...@hpe.com<mailto:tom.camm...@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 <yuany...@oeilvert.org<mailto:yuany...@oeilvert.org>> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> >> Date: Monday, 16 May 2016 at 01:07 >> To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org<mailto:openstack-dev@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...@huawei.com<mailto:hongbin...@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-requ...@lists.openstack.org?subject:unsubscribe<http://OpenS >> tack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:tack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
