<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">For reference, the current list of objects and actions used by commands in the OSC repo are at <a href="http://docs.openstack.org/developer/python-openstackclient/commands.html">http://docs.openstack.org/developer/python-openstackclient/commands.html</a>.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Also note that while the OSC team may have multiple opinions on what fits well and does not in plugins, the plugins are owned by the project teams and not the OSC team and we do not rigidly enforce our structure on external plugins. Inconsistencies in command structure work against the entire spirit of why OSC was built to begin with.  For external plugins, however, we will rely on community feedback to encourage projects to stay consistent as much as possible.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, May 25, 2015 at 9:52 AM, Ronald Bradford <span dir="ltr"><<a href="mailto:me@ronaldbradford.com" target="_blank">me@ronaldbradford.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 dir="ltr"><div>2. "execute" or "exec"<br></div><div><br></div><div>This is clearly a new type of action that requires OSC to provide recommended guidance on. I am 50/50 here.</div></div></blockquote><div><br></div><div>To add a new action I think you need to be clear for the user what it does and hopefully in a way that is not unique to this command.  Many of the actions in the docs are specific to servers because they only appear in server commands.  These can/should be generalized where possible in favor of adding new actions.</div><div><br></div><div>I don't see anything that fits what I would expect an 'execute' action to do, but then I also don't quite know what this is intended to do.  In the context of the container command example above, there is execute, start and stop.  start and stop seem to be create and delete equivalents to the server commands.  If you choose to deviate from that, you should explain exactly why and how so the user can figure out the difference.</div><div><br></div><div>I don't know what execute does in that context.  Is a container created in a paused/suspended state?</div><div><br></div><div>Also, I'm not a fan of adding yet another set of running state action pairs (create/delete, pause/unpause, suspend/resume).</div><div> </div><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 dir="ltr"><div>3. "set" or "update"</div><div><br></div><div>While I consider the word "set" to be more an attribute specific term, "update" implies a change of multiple attributes. If I just looked at the usage I would say "update".  However, looking at the actual usage openstack client set syntax uses named parameters to set multiple parameters.</div></div></blockquote><div><br></div><div>Most people's update is OSC's set.  There is also unset for removing an attribute rather than setting it to a null value.  Set is generally very similar to create command-wise.</div><div> </div><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 dir="ltr"><div><div>Looking into the help syntax of a Magnum "update" option, I find it supports "add", "replace" and "remove" operations.  This complicates matters</div></div></div></blockquote><div><br></div><div>We already have the concept of adding and removing resources from other containing resources.  Look at security groups for the best example.  This is also one of the only places we use more than one positional parameter, the rationale being you have two resources in the command itself, both can be referenced in the args implicitly.</div><div> </div><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 dir="ltr"><div>4. "service" is already used by Identity. See  <a href="http://docs.openstack.org/developer/python-openstackclient/command-objects/service.html" target="_blank">http://docs.openstack.org/developer/python-openstackclient/command-objects/service.html</a><br></div><div><br></div><div>5. "container" is already used by Swift. See  <a href="http://docs.openstack.org/developer/python-openstackclient/command-objects/container.html" target="_blank">http://docs.openstack.org/developer/python-openstackclient/command-objects/container.html</a></div></div></blockquote><div><br></div><div>We need to go to multiple word objects here then.  Backward compatibility gives the bare object name to the existing commands, although I would suggest we add a qualified object name also: 'service' might become 'catalog service' as an alas.  We document those and ride out a really long deprecation for something so fundamental.</div><div> <br></div><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 dir="ltr"><div>I have no suggestions on 4. and 5.</div><div>Given these last 2 entanglements the OSC will quickly become unusable as more clients which it integrate.</div></div></blockquote><div><br></div><div>Yup, this is a problem.  We need to anmespace things somehow, be it by putting the commands into a namespace like congressclient did (all commands start with 'congress', I'd have suggested not using the project name), or we namespace the objects as I suggested earlier by using longer and more specific names.</div><div><br></div><div>Or we don't attempt to put the entire big tent client commands into a single CLI.  There is nothing that says we can't have multiple top-level commands.  OSC today doesn't easily do that and leverage the existing code structure, but it probably could if this becomes a popular option.  The 'openstack' command for the usual and common stuff, and a (pulling names out of my hat here): 'os-tent' for big-tent-related commands (I'm taking this part literally) and 'os-jewel' for the sparkly, shiny commands that make brides happy:</div><div><br></div><div>os-tent ring create --type elephant dumbo</div><div>os-jewel ring create --type wedding sparkle</div><div><br></div></div><div>In the end, the principle of 'least surprise' is important to consider.  And that I still maintain the 'C' in OSC stands for 'Consistent'.</div><div><br></div><div>dt</div><div><br></div><div><br></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>