Open Stack

Excerpts from Tim Bell's message of 2015-09-02 18:50:57 +0000:
> > -----Original Message-----
> > From: Doug Hellmann [mailto:doug at doughellmann.com]
> > Sent: 02 September 2015 16:21
> > To: openstack-dev <openstack-dev at lists.openstack.org>
> > Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin
> > 
> > Excerpts from Tim Bell's message of 2015-09-02 05:15:35 +0000:
> > > That would be great to have plugins on the commands which are relevant
> > to multiple projects… avoiding exposing all of the underlying projects as
> > prefixes and getting more consistency would be very appreciated by the
> > users.
> > 
> > That works in some cases, but in a lot of cases things that are superficially
> > similar have important differences in the inputs they take. In those cases, it's
> > better to be explicit about the differences than to force the concepts together
> > in a way that makes OSC present only the least-common denominator
> > interface.
> > 
> 
> 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.

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.

Placing "baremetal" as the first part of the command was an intentional
choice -- we call this the "noun first" form, versus the "verb
first" form "create baremetal". We considered that the user understands
what kind of resource they're trying to issue a command on, but may
not know all of the commands available for that resource type. With
tab-completion enabled, "openstack baremetal<TAB>" will give them
the list of commands for doing anything to baremetal servers. It
also means all of the commands for a given resource type are listed
together in the global help output where we list all available
subcommands.

> 
> At CERN, we're using OSC as the default CLI. This is partly because the support for Keystone v3 API is much more advanced but also because we do not want our end users to know the list of OpenStack projects, only the services we are offering them.

Using resource type names rather than services is definitely
preferred. That falls down when we have 2 services providing similar
(or the same) resource types. For example, I could see some overlap
in command names and resource types for Cue and Zaqar.

Doug

> 
> Tim
> 
> > Doug
> > 
> > >
> > > Tim
> > >
> > > From: Dean Troyer [mailto:dtroyer at gmail.com]
> > > Sent: 01 September 2015 22:47
> > > To: OpenStack Development Mailing List (not for usage questions)
> > > <openstack-dev at lists.openstack.org>
> > > Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin
> > >
> > > [late catch-up]
> > >
> > > On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann
> > <doug at doughellmann.com<mailto:doug at doughellmann.com>> wrote:
> > > Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:
> > > > On 24/08/15 18:19 +0000, Tim Bell wrote:
> > > > >
> > > > >From a user perspective, where bare metal and VMs are just different
> > flavors (with varying capabilities), can we not use the same commands
> > (server create/rebuild/...) ? Containers will create the same conceptual
> > problems.
> > > > >
> > > > >OSC can provide a converged interface but if we just replace '$ ironic
> > XXXX' by '$ openstack baremetal XXXX', this seems to be a missed
> > opportunity to hide the complexity from the end user.
> > > > >
> > > > >Can we re-use the existing server structures ?
> > >
> > > I've wondered about how users would see doing this, we've done it already
> > with the quota and limits commands (blurring the distinction between
> > project APIs).  At some level I am sure users really do not care about some of
> > our project distinctions.
> > >
> > > > To my knowledge, overriding or enhancing existing commands like that
> > > > is not possible.
> > >
> > > You would have to do it in tree, by making the existing commands smart
> > > enough to talk to both nova and ironic, first to find the server
> > > (which service knows about something with UUID XYZ?) and then to take
> > > the appropriate action on that server using the right client. So it
> > > could be done, but it might lose some of the nuance between the server
> > > types by munging them into the same command. I don't know what sorts
> > > of operations are different, but it would be worth doing the analysis
> > > to see.
> > >
> > > I do have an experimental plugin that hooks the server create command to
> > add some options and change its behaviour so it is possible, but right now I
> > wouldn't call it supported at all.  That might be something that we could
> > consider doing though for things like this.
> > >
> > > The current model for commands calling multiple project APIs is to put
> > them in openstackclient.common, so yes, in-tree.
> > >
> > > Overall, though, to stay consistent with OSC you would map operations
> > into the current verbs as much as possible.  It is best to think in terms of how
> > the CLI user is thinking and what she wants to do, and not how the REST or
> > Python API is written.  In this case, 'baremetal' is a type of server, a set of
> > attributes of a server, etc.  As mentioned earlier, containers will also have a
> > similar paradigm to consider.
> > >
> > > dt
> > >
> > 
> > ________________________________________________________________
> > __________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> > request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev