juju command progress ui

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

...

> 
>> - deployment seems to hang for ages, then the command returns,
>> but it's still not deployed
> 
> We can solve that misunderstanding trivially while preserving all
> the above properties by adding a warning message when the
> environment is not bootstrapped:
> 
> warning: this can take several minutes because the environment is 
> still bootstrapping
> 
> But I'm starting to repeat myself.

I think you're missing where the user's misunderstanding is. I'm not
sure if we can just re-educate our users.

Normally, you make a request for X, and if that takes a while, it is
because it is finishing X and then returns.

Instead, juju is using the logic, request X, return as soon as the
preconditions for X have been satisfied such that it is expected X
will eventually succeed.
Which means that the *next* command is actually the one that verifies
that the previous one has actually finished, but then doesn't verify
that the thing you just requested has finished.

Which leads to a mental mismatch between expectations and actual
actions. It is possible we can fix this with user-visible messages (eg
juju bootstrap runs and prints "requested the bootstrap node to start,
it should be ready in a few minutes").

For many of us, it would seem better to give progress messages (state
server is starting
.
.
.
state server has started)

If you gave those sorts of messages, then a user could choose to ^C
after the starting message, understanding that they don't have to wait
for it to finish, but then it will match their internal model that
after running "juju X" when X returns it will have been completed.

Similarly for stuff like 'juju deploy'. I realize it can take a while,
but I think that means users would really like to see updates as to
how far along it has come.

The people I've talked to essentially fall back to polling 'juju
status' manually to find out when their request has actually completed.

I do understand the "I have 100 pieces of state to update, and then I
want to be informed when some of it is at a point that I can start
using/configuring/etc it".

Maybe "juju deploy --wait" ?(--monitor/--interactive/whatever).

Or is this more "juju status -f" (akin to 'tail -f').

However, that doesn't have quite enough context to know what operation
you are waiting for vs 'juju deploy --wait' knows that we are waiting
for that specific deploy to wait.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEvTdsACgkQJdeBCYSNAANvjQCfWp1SmohgGYkz6XnHstbG/M6u
IooAoNNectvn41RHKfz4fnNmQb6RcgB3
=64fe
-----END PGP SIGNATURE-----