openstack team mailing list archive

[Adam Spiers <aspiers@xxxxxxxx>]

Doug Hellmann (doug.hellmann@xxxxxxxxxxxxx) wrote:
> On Mon, Apr 30, 2012 at 12:13 PM, Adam Spiers <aspiers@xxxxxxxx> wrote:
> 
> > Dean Troyer (dtroyer@xxxxxxxxx) wrote:
> > > One of the first things to do is to find out who is interested in
> > > contributing to this project.and hopefully coordinating some of the
> > > work with the other emerging project-specific clients.  Send me an
> > > email and I'll build a list to get the discussion started.
> >
> > Count me in - by 'build a list' do you mean a new mailing list?
> >
> > I've read http://wiki.openstack.org/UnifiedCLI/HumanInterfaceGuidelines
> > (which looks like a great start on the topic!) and made some minor
> > tweaks.  Should we discuss the FIXMEs you marked here or elsewhere?  I
> > wanted to make a few suggestions before I forget - can always continue
> > discussion elsewhere if appropriate:
> >
> >  1. Regarding "The subject names are always specified in command in
> >     their singular form.  This is contrary to natural language use."
> >
> >       - I didn't understand the second sentence here, but shouldn't the
> >         HIG should allow for scenarios where the verb can operate both on
> >         individual objects and on multiple objects in batch?
> 
> I read that as meaning the command to list instances available to a tenant
> should be "list server" not the more natural "list servers".

Ah I see - makes sense now, thanks.

> Can you give an example of a command that would work on multiple objects in
> batch?

Things like

    openstack set hosts --name-matches='foo*' --maintenance enable

    # use with caution! would require confirmation prompt
    openstack delete images --name-matches='bar*'

?

> Running a cliff-based app without any arguments enters "interactive" mode
> (as of 0.4) which gives the user a new prompt and lets them run multiple
> commands before exiting. This is intended to be used as an optimization for
> commands to cache authentication credentials and clients and avoid logging
> in for every sub-command.

I love it :-)  I guess it has readline support and could also offer
completion too?

Forgive the newbie question, but does cliff have significantly
different goals or scope to cement?  I attended the Quantum CLI
rewrite session at the summit:

  http://folsomdesignsummit2012.sched.org/event/b20c2743ac6ab35d4f33b4fcd1da4fa7

and IIRC they were going to move to using cement.  The notes from that
session start on line 224 of:

  http://etherpad.openstack.org/quantum-folsom

In particular note: "Need to do some cleanup before the One CLI to
Rule Them All project is going to be far enough long to be usable for
Quantum commands".  I wasn't sure how the work with cement would
dovetail with this project though.

> Since we're using argparse for the subcommands, the default behavior if a
> command is run without arguments depends on the subcommand. If the
> subcommand has no required arguments, it will do whatever it is meant to
> do. If it does require arguments and sees none, argparse prints an error
> message about whatever is missing

Agreed, except ...

> (and possibly suggests that the user use --help to get
> instructions).

One of my pet peeves is commands which tell you that you screwed up
but don't immediately offer help so you can take appropriate remedial
action.  In other words, bearing in mind Dean's section on
"User-Centered Design" in the HIG, I'd prefer a command outputted
usage text along with an error than one or two sentences forcing you
to rerun the command with the --help option.