Open Stack

On Tue, Nov 10, 2015 at 6:19 AM, Sam Betts (sambetts) <sambetts at cisco.com>
wrote:

> 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.
>

This list is a good starting point.

OSC's command format is <object> <action> [...stuff]

Where <object> is the resource being manipulated (there is also provision
for when there are two objects, we'll tackle that when it comes up).  Also
note that resources may have multiple-word names, in Ironic's case that
includes the 'baremental' word for disambiguation.

<action> is the operation to be done with the resource, and should as far
as reasonable re-use the existing defined actions as Steve already
mentioned.  Things like 'manage' or 'maintain' seem meaningless to me and
may be best implemented as setting state via 'set' instead if that is what
they apparently do.

So the resources I see above are node, chassis, port and driver.

In options, the preference is to define fewer options directly and use
option arguments.  for example, above I see:

  'baremetal node boot device [--pxe|--cdrom] <id>'

I would suggest that:

  'baremetal node boot device [--type pxe|cdrom] <id>'

is preferable as only one option is defined that takes an argument.  The
reeason for this is to try and balance the constantly changing options (as
types are added/removed) against changing the CLI and causing help screen
bloat.

Also, and I know this is hard, but free yourself from being tied exactly to
the REST API. The primary user here is likely to not be familiar with the
GET/POST/PUT requests and doesn't really care if all of the names and
actions do not match exactly.  For designing the CLI, think about the
actions the user perceives being performed and how to meet those
expectations, not about how it is implemented on the back side.

There may be places where to the user a baremetal action is an apparent
overlap with a compute action.  If the distinction is not necessary for the
user but something that OSC can figure out on its own (ie is baremental in
the service catalog? etc) then we should consider merging the commands.
 (Disclaimer: for things in the OSC repo this works (see limits, quota) but
it has not been satisfactorily solved for plugins.  If we need it we'll
move up its priority.)

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151110/6bf3becd/attachment.html>