juju command progress ui

[Gustavo Niemeyer]

On Thu, Feb 28, 2013 at 12:57 AM, Julian Edwards
<julian.edwards at canonical.com> wrote:
> Are you defining its task differently to me?  Bootstrap is asynchronous,
> so it returns you to the prompt as soon as the request went to the
> provider.  I've seen it return in half a second when bootstrapping a
> MAAS environment.
>
> Given that if you then try to deploy, the deployment inexplicably blocks
> until some apparently random later time.  This feels like a poor user
> experience to me.

We should have a warning message in those cases to make the situation
more clear, but I disagree that the proposal makes the situation
better, as detailed below.

> It makes far more sense from a user's point of view to block at the
> point where the delay is really happening.  I don't see that as

Saying that the delay really happens in the bootstrap command is like
saying that the delay for an SMTP message to reach its target really
happens in your mail client.

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.

> artificial at all - in fact it feels more artificial when "deploy"
> blocks because the bootstrap isn't done yet.  I'd feel better if it
> queued the deployment and returned immediately to the prompt.  Can you
> see how this is inconsistent?

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.

For your suggestion to be consistent, the deploy command would
have to wait until the machines were all alive, and their respective
services working. That's not a good user experience either.


gustavo @ http://niemeyer.net