<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 10, 2015 at 6:19 AM, Sam Betts (sambetts) <span dir="ltr"><<a href="mailto:sambetts@cisco.com" target="_blank">sambetts@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<div style="word-wrap:break-word">
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
So you would end up with a set of commands that look like this:</div>
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<br>
</div>
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Openstack baremetal [node/driver/chassis] list</div>
<div>Openstack baremetal port list [—node uuid] <— replicate node-port-list </div>
<div><br>
</div>
<div>Openstack baremetal [node/port/driver] show UUID</div>
</div>
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
Openstack baremetal chassis show [—nodes] UUID  <— replicate chassis-node-list </div>
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<br>
</div>
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Openstack baremetal [node/chassis/port] create</div>
<div>Openstack baremetal [node/chassis/port] update UUID</div>
<div>Openstack baremetal [node/chassis/port] delete UUID</div>
<div><br>
</div>
<div>
<div>Openstack baremetal [node/chassis] provide UUID</div>
<div>Openstack baremetal [node/chassis] activate UUID</div>
</div>
<div>Openstack baremetal [node/chassis] rebuild UUID</div>
<div>Openstack baremetal [node/chassis] inspect UUID</div>
<div>Openstack baremetal [node/chassis] manage UUID</div>
<div>Openstack baremetal [node/chassis] abort UUID</div>
</div>
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Openstack baremetal [node/chassis] boot UUID</div>
<div>Openstack baremetal [node/chassis] shutdown UUID</div>
<div>Openstack baremetal [node/chassis] reboot UUID</div>
</div>
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<br>
</div>
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
Openstack baremetal node maintain [—done] UUID</div>
<div style="color:rgb(0,0,0)"><font face="Calibri,sans-serif" style="font-size:14px">Openstack baremetal node console [—enable, —disable] UUID <—
</font>With no parameters this acts like node-get-console, otherwise acts like node-set-console-mode</div>
<div><font face="Calibri,sans-serif">Openstack baremetal node boot-device [—supported, —PXE, —CDROM, etc] UUID <—</font> 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</div>
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<br>
</div>
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
Openstack baremetal [node/driver] passthru</div>
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<br>
</div>
<div style="color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
WDYT? I think I’ve covered most of what exists in the Ironic CLI currently. </div></div></blockquote><div><br></div><div>This list is a good starting point.</div><div><br></div><div>OSC's command format is <object> <action> [...stuff]</div><div><br></div><div>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.</div><div><br></div><div><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.</div><div><br></div><div>So the resources I see above are node, chassis, port and driver.</div><div><br></div><div>In options, the preference is to define fewer options directly and use option arguments.  for example, above I see:</div><div><br></div><div>  'baremetal node boot device [--pxe|--cdrom] <id>'</div><div><br></div><div>I would suggest that:</div><div><div><br class="">  'baremetal node boot device [--type pxe|cdrom] <id>'</div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div>dt</div><div><br></div></div>-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>