On Tue, Nov 10, 2015 at 6:19 AM, Sam Betts (sambetts) <sambe...@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 dtro...@gmail.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