juju command progress ui

[Gustavo Niemeyer]

On Thu, Feb 28, 2013 at 2:35 AM, Julian Edwards
<julian.edwards at canonical.com> wrote:
>> Having a client command that blocks for 10 minutes doing absolutely
>> nothing while the provider decides to allocate a new machine on its
>> own time seems to me like a pretty poor user experience.
>
> This is exactly what "juju deploy" does if you run it immediately after
> bootstrap returns.

That's not correct, and I've explained why:

Bootstrap blocks while its intention isn't *requested*, at which point
there's nothing else for this command to do. The deploy command
blocks while its intention isn't *requested*, at which point there's
nothing else for this command to do.

> The end user doesn't care so much about completion of the request as
> much as the completion of the whole operation - bootstrap and deployment

I can't tell what the user really cares about or not, but I can
describe in detail what the user experience that we're putting in
place.

1) juju bootstrap + juju deploy just work
2) juju bootstrap blocks until its request is processed; after that
you can turn your laptop off, and go to lunch, or execute another
bootstrap.
3) juju deploy blocks until its request is processed; after that you
can turn you laptop off, and go have some coffee
4) If juju deploy blocks, it means the request wasn't processed yet
5) If you cancel while juju deploy is blocked waiting for a bootstrap,
you actually cancel the deployment
6) Points 1, 3, 4, and 5 are not special to juju deploy. All commands
work that way.


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


gustavo @ http://niemeyer.net