On 11/10/2015 03:32 PM, Steve Martinelli wrote:
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?
inspect, manage, provide, active and abort are all provisioning verbs
used in ironic API. they usually represent some complex operations on a
node. Inspection is not related to showing, it's about fetching hardware
properties from hardware itself and updating ironic database. manage
sets a node to a specific ("manageable") state. etc.
boot and shutdown are natural opposites, aka power on and power off.
reboot and rebuild seem good
/rant
Steve
Inactive hide details for "Sam Betts (sambetts)" ---2015/11/10 07:20:54
AM---So you would end up with a set of commands that lo"Sam Betts
(sambetts)" ---2015/11/10 07:20:54 AM---So you would end up with a set
of commands that look like this: Openstack baremetal [node/driver/cha
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" <_wanghaomeng@gmail.com_
<mailto:wanghaom...@gmail.com>>*
Reply-To: *"OpenStack Development Mailing List (not for usage
questions)" <_openstack-dev@lists.openstack.org_
<mailto: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_
<mailto: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)
<_sambetts@cisco.com_ <mailto: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" <_wanghaomeng@gmail.com_
<mailto:wanghaom...@gmail.com>>*
Reply-To: *"OpenStack Development Mailing List (not for usage
questions)" <_openstack-dev@lists.openstack.org_
<mailto: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_
<mailto: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
<_pshchelokovskyy@mirantis.com_
<mailto: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
<_lucasagomes@gmail.com_ <mailto: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://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://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://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
