juju command progress ui

[Ian Booth]

We discussed thus issue in the recent weekly juju meeting and agreed to move the
conversation to the list.

TL;DR; - what feedback should (long running, background) juju commands provide

The topic of conversation resolves around how/if we should provide visible
feedback to the user about the progress of juju commands. The issue arose when
we were discussing the behaviour of the bootstrap command in particular. The
bootstrap process takes a while (minutes) to complete yet "juju bootstrap"
returns after the bootstrap process is instantiated. The current expectation as
I understand it is that users would then run "juju deploy xxx" (which will block
until the bootstrap process is complete), or they can run "juju status" as a
means to poll the bootstrap node to see if it is ready.

I understand that an implementation goal of juju is to make things "just work"
so that the user doesn't have to think too much and that running any command can
be expected to complete successfully. While I agree with this principal, many
users (myself included) want and expect more insight into the progress of any
long running commands in order to be reassured that things are progressing as
expected, and to be able to understand any errors which will occur despite best
efforts.

I am a novice juju user (even though I've obviously worked on the code, being a
*user* of the product brings a very different perspective). Having used and
developed many other products' UI previously, I have certain personal
expectations and previous feedback from users as to how things "should" work.
What follows are my personal thoughts, IMHO and all that.

The issue I'm raising was highlighted to me when I was testing juju using HP
Cloud and had bootstrapped a new environment. The bootstrap command returned
without error but the bootstrap node was subsequently unusable (and hence so was
the deployment) due to an as yet undetermined internal error starting the node
properly. Running with debug I got info about uploading tools and finally a
"started instance" message, but nothing further about the success or otherwise
of the node startup. At this point, the process becomes a black hole and I'm
forced to run "juju status" over and over to poll the node or try my luck
running "juju deploy" and see what happens.

What I would ideally have loved to have seen was some sort of progress
indication as to how the bootstrap is progressing. Whether the bootstrap command
should block or not until done can also be discussed, but I'd love to see at the
least a series of "." (or even messages) printed to the console as the various
bootstrap steps complete, and an error message when/if something in the startup
process fails. I do feel that even though many (most?) users of juju may not
care so much about the detailed internal mechanisations, they will be technical
users of sorts and want a little more than just a Joe Average blackbox, totally
opaque system. Or at least an option to get some sort of feedback on the
progress of "background" commands that need to complete in order for the system
to be usable.

In my own bootstrap case, I have a theory as to what failed, but it's as yet
only a theory and ssh'ing into the machine to inspect the logs didn't show too
much about the root cause (to me). There were entries saying that logging in to
the juju database failed, but why? Why was the correct password not used? What
prevented it from being determined? etc It would be nice if we could do a better
job here, in that given the node is broken, tell the user what the ultimate root
cause is and what config or other tweaks are needed to fix it. And do so in such
a way that it can be reported to the console from which the bootstrap command
was invoked instead of forcing the user to ssh in and poke around the logs. Or
have them be surprised when deploy doesn't work because bootstrap appeared to work.

As a side note (remember, novice user here), I had to go to the HP Cloud web
console to figure out the magic command options to ssh in to the node. It would
be nice if when the node was started, it could be printed out the exact ssh
command if need be. Or is there a "juju ssh" command which knows how to do the
right thing for each provider/environment? If not, should there be?

Ok, if you've got this far, congratulations, go get a life :-) Jokes aside, any
and all opinions welcome.