Open Stack

On Wed, Sep 2, 2015 at 2:29 PM, Doug Hellmann <doug at doughellmann.com> wrote:

> Excerpts from Tim Bell's message of 2015-09-02 18:50:57 +0000:
> > 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.
> >
> > 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.
>
> This is the long-standing debate over whether it's better to constrain
> the inputs up front, or accept anything and then validate it and
> reject bad inputs after they are presented. My UI training always
> indicated that assisting to get the inputs right up front was better,
> and that's what I think we're trying to do with OSC.
>
> Having an "openstack server create" command that works for all
> services that produce things that look like servers means the user
> has to somehow determine which of the options are related to which
> of the types of servers. We can do some work to group options in
> help output, and express which are mutually exclusive, but that
> only goes so far. At some point the user ends up having to know
> that when "--type baremetal" is provided, the "--container-type"
> option used for containers isn't valid at all. There's no way to
> express that level of detail in the tools we're using right now,
> in part because it results in a more complex UI.
>

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.


> Having an "openstack baremetal create" command is more like the
> up-front constraint, because the user can use --help to discover
> exactly which options are valid for a baremetal server. It shifts
> that "--type baremetal" option into the command name, where the
> tools we use to build OSC can let us express exactly which other
> options are valid, and (implicitly) which are not.
>

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.

dt

-- 

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