openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Tue, May 1, 2012 at 2:35 PM, Adam Spiers <aspiers@xxxxxxxx> wrote:

> 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?
>

Yes, it uses cmd2 for the interaction, so readline is supported, where
available.


>
> 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.
>

Dean and I looked at cement and didn't feel it was a good fit (also, it
looked like it would be cumbersome to use). cliff is a new framework that
more directly meets the requirements we have, especially giving extensions
the ability to load new commands dynamically.


>
> > 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.
>

We can probably make them print help by default.