Open Stack

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)" <sambetts at cisco.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at 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 at gmail.com_
> <mailto:wanghaomeng at gmail.com>>*
> Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <_openstack-dev at lists.openstack.org_
> <mailto:openstack-dev at lists.openstack.org>>*
> Date: *Tuesday, 10 November 2015 11:41*
> 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] [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 at cisco.com_ <mailto:sambetts at 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 at gmail.com_
>     <mailto:wanghaomeng at gmail.com>>*
>     Reply-To: *"OpenStack Development Mailing List (not for usage
>     questions)" <_openstack-dev at lists.openstack.org_
>     <mailto:openstack-dev at lists.openstack.org>>*
>     Date: *Tuesday, 10 November 2015 10:49*
>     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] [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 at mirantis.com_
>     <mailto:pshchelokovskyy at 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 at gmail.com_ <mailto:lucasagomes at 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-request at lists.openstack.org?subject:unsubscribe_
>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe_
>     <http://OpenStack-dev-request@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://OpenStack-dev-request@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
>