juju command progress ui

[Clint Byrum]

Excerpts from Gustavo Niemeyer's message of 2013-02-28 07:00:09 -0800:
> On Thu, Feb 28, 2013 at 11:54 AM, John Arbash Meinel
> <john.meinel at canonical.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >> Doing CTRL-C when an action command is in progress with zero
> >> consequence sounds pretty surprising (re-education?).
> >
> > I ^C watch, tail, top, and several other things that are just doing
> > monitoring.
> 
> Exactly. "juju bootstrap" is not just doing monitoring. Should be
> innocuous to CTRL-C "juju observe", though.
> 
> > The main difference is that deploy --wait would return once the thing
> > you specifically requested was running. Vs 'observe' being a separate
> > command not having the context of what you are interested in waiting on.
> 
> I do hope we're able to say "juju observe myservice", and
> "myservice/0", and other useful filterings. Otherwise this command
> will become a fire hose pretty quickly.
> 
> 

I've been playing with Heat quite a bit lately, and a few things strike
me from this discussion.

* bootstrap is non-existant because Heat is run inside OpenStack. Heat's
bootstrap is devstack, or apt-get install heat... so there's no analog
for the problem of starting with nothing. This feels more natural as
a user and developer. I can separate "running things on heat" from
"running heat".  It is, of course, far less convenient.

* After creating a stack of things in heat, one polls the 'event-list'
command to see what is going on. The events are categorized by state
changes for each resource. The details of the cloud are not so hidden
from the user either, since their keystone details that let them do heat
commands also allow nova commands and such, so often one finds themselves
doing something like this:

heat event-list mybigstack
heat event-show mybigstack event-uuid-from-problem
nova console-log server-that-failed

Given that experience, I have a few suggestions:

* The observe command would do well to have a structured output rather
than a raw log. Make it a drill down summary. juju status is too "what
is the state of all things now?". I want to know what happened, not
whats happening. And as Gustavo says, I don't want a firehose.

* I tend to agree that commands that dispatch things to other places
should just return immedately. A Warning is not advisable though. What
would be better would be helping the user know wtf juju just did:

$ juju bootstrap
{instance:abcdefg-12354-deadbeef19348-4418914913, state:BUILD, environment:hpcloud-az3}
$

While you can of course have the observe command abstract the observation,
rather than make it opaque, *help* me use the cloud tools that I have
to observe that instance for bootstrap.  Don't assume that juju knows
everything that I want to observe about this process.