<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 2, 2015 at 2:29 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Tim Bell's message of 2015-09-02 18:50:57 +0000:<br><span class="">> I think the difference are in the options rather than the prefixes. Thus, if I want to create a bare metal server, I should be able to use 'openstack create' rather than 'openstack ironic create'. The various implications on options etc. are clearly dependent on the target environment.<br>
><br>
> I would simply like to avoid that the OSC becomes a prefix, i.e. you need to know that ironic is for baremetal. If options are presented which are not supported in the desired context, they should be rejected.<br>
<br>
</span>This is the long-standing debate over whether it's better to constrain<br>
the inputs up front, or accept anything and then validate it and<br>
reject bad inputs after they are presented. My UI training always<br>
indicated that assisting to get the inputs right up front was better,<br>
and that's what I think we're trying to do with OSC.<br>
<br>
Having an "openstack server create" command that works for all<br>
services that produce things that look like servers means the user<br>
has to somehow determine which of the options are related to which<br>
of the types of servers. We can do some work to group options in<br>
help output, and express which are mutually exclusive, but that<br>
only goes so far. At some point the user ends up having to know<br>
that when "--type baremetal" is provided, the "--container-type"<br>
option used for containers isn't valid at all. There's no way to<br>
express that level of detail in the tools we're using right now,<br>
in part because it results in a more complex UI.<br></blockquote><div><br></div><div>To do this now requires manually implementing it in the commands themselves, but I am willing to do that as I do think the end result is a lower footprint UI.  The biggest problem we have is the help output, that is not solved yet, but we have been clear in the documentation when options are only applicable with or without other options also present.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Having an "openstack baremetal create" command is more like the<br>
up-front constraint, because the user can use --help to discover<br>
exactly which options are valid for a baremetal server. It shifts<br>
that "--type baremetal" option into the command name, where the<br>
tools we use to build OSC can let us express exactly which other<br>
options are valid, and (implicitly) which are not.<br></blockquote><div><br></div><div>We have started using multiple word nouns for disambiguation, in this case, I would suggest 'baremetal server' as 'baremetal' is not a thing by itself.  I think this is an acceptable compromise as it still contains 'server' as the concepts involved are fundamentally the same thing.  'server create --type baremental' would still be my preference, even with it being more work inside OSC/plugins.</div><div></div></div><div><br></div><div>dt</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>