Open Stack

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)" <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>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
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>
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>
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>
  Reply-To: "OpenStack Development Mailing List (not for usage questions)"
  <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>
  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> 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> 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://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://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/20151110/df4fcca9/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/20151110/df4fcca9/attachment.gif>