So I don't know the intricacies of the baremetal APIs, but hopefully I can shed some light on best practices.
Do try to reuse the existing actions ( http://docs.openstack.org/developer/python-openstackclient/commands.html#actions ) Do use "create", "delete", "set", "show" and "list" for basic CRUD. Do try to have natural opposites - like issue/revoke, resume/suspend, add/remove. So looking at the list below, I'd say: Don't use "update" - use "set". What's the point of "inspect"? Can you use "show"? If it's a HEAD call, how about "check"? What's "manage" does it update a resource? Can you use "set" instead? What are the natural opposites between provide/activate/abort/boot/shutdown? reboot and rebuild seem good /rant Steve From: "Sam Betts (sambetts)" <sambe...@cisco.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 2015/11/10 07:20 AM Subject: Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action So you would end up with a set of commands that look like this: Openstack baremetal [node/driver/chassis] list Openstack baremetal port list [?node uuid] <? replicate node-port-list Openstack baremetal [node/port/driver] show UUID Openstack baremetal chassis show [?nodes] UUID <? replicate chassis-node-list Openstack baremetal [node/chassis/port] create Openstack baremetal [node/chassis/port] update UUID Openstack baremetal [node/chassis/port] delete UUID Openstack baremetal [node/chassis] provide UUID Openstack baremetal [node/chassis] activate UUID Openstack baremetal [node/chassis] rebuild UUID Openstack baremetal [node/chassis] inspect UUID Openstack baremetal [node/chassis] manage UUID Openstack baremetal [node/chassis] abort UUID Openstack baremetal [node/chassis] boot UUID Openstack baremetal [node/chassis] shutdown UUID Openstack baremetal [node/chassis] reboot UUID Openstack baremetal node maintain [?done] UUID Openstack baremetal node console [?enable, ?disable] UUID <? With no parameters this acts like node-get-console, otherwise acts like node-set-console-mode Openstack baremetal node boot-device [?supported, ?PXE, ?CDROM, etc] UUID <? With no parameters this acts like node-get-boot-device, ?supported makes it act like node-get-supported-boot-devices, and with a type of boot device passed in it’ll act like node-set-boot-device Openstack baremetal [node/driver] passthru WDYT? I think I’ve covered most of what exists in the Ironic CLI currently. Sam From: "Haomeng, Wang" <wanghaom...@gmail.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Date: Tuesday, 10 November 2015 11:41 To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action Hi Sam, Yes, I understand your format is: #openstack baremetal <action> <uuid> so these can cover all 'node' operations however if we want to cover support port/chassis/driver and more ironic resources, so how about below proposal? #openstack baremetal <resource/target> <action> <uuid> The resource/target can be one item in following list: node port chassis driver ... Make sense? On Tue, Nov 10, 2015 at 7:25 PM, Sam Betts (sambetts) <sambe...@cisco.com> wrote: Openstack baremetal provision provide or ?provide Just doesn’t feel right to me, it feels like I am typing more that I need to and it feels like I’m telling it to do the same action twice. I would much rather see: Openstack baremetal provide UUID Openstack baremetal activate UUID Openstack baremetal delete UUID Openstack baremetal rebuild UUID Openstack baremetal inspect UUID Openstack baremetal manage UUID Openstack baremetal abort UUID And for power: Openstack baremetal boot UUID Openstack beremetal shutdown UUID Openstack baremetal reboot UUID WDYT? Sam From: "Haomeng, Wang" <wanghaom...@gmail.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Tuesday, 10 November 2015 10:49 To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action How about below format? #openstack baremetal <resource/target> <action> <uuid> Example: #openstack baremetal provision provide <UUID> #openstack baremetal power on/off <UUID> I think it is easy to understand and remember:) On Tue, Nov 10, 2015 at 6:17 PM, Pavlo Shchelokovskyy < pshchelokovs...@mirantis.com> wrote: Hi, I like the last variant by Lucas, and agree we need to ensure the CLI interface is consistent between power and provision commands. Best regards, On Tue, Nov 10, 2015 at 12:00 PM Lucas Alvares Gomes < lucasago...@gmail.com> wrote: > It's still not 100% consistent, "power" is a noun, "provision" is a verb. > Not sure it matters, though, adding OSC folks so that they can weigh in. > "provision" can also be a noun [1]. But since the OSC syntax suggest having a verb we could have something like: $ openstack baremetal set power --on | --off <UUID> $ openstack baremetal set provision --provide | --active | ... <UUID> [1] http://www.thefreedictionary.com/provision __________________________________________________________________________ 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 -- Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com __________________________________________________________________________ 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 __________________________________________________________________________ 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 __________________________________________________________________________ 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
__________________________________________________________________________ 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