juju command progress ui

[Julian Edwards]

Hello Gustavo, thanks for your response.

On 28/02/13 15:05, Gustavo Niemeyer wrote:
> 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.

I agree that some extra output would be useful.

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

I don't see that analogy at all, sorry.  I am not waiting to do
something else after I send an email, it's gone and that's that.  The
fact is that bootstrap returns before bootstrapping is actually finished.

> 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.  Do you agree that's a 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.

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
in this case.  In simple terms, it's not done when the request finishes,
it's done at some point in the future.

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

I think you misunderstood me.  The inconsistency arises because one is
blocked on the other, but the end user doesn't care about that.  They
just want to deploy a service and what they see is that:

 - bootstrap is really quick!
 - deployment seems to hang for ages, then the command returns, but it's
still not deployed

When I first used Juju, this confused the heck out of me because it was
before I understood its architecture a bit less than I do now.  I just
think we can work a bit harder to improve this with better and more
feedback to the user.  And I am saying this mostly as a user who got
confused, and that's pretty much always a problem with the software not
the user - unless the user is too stupid to be in front of a computer,
which I don't think I am :)

Cheers
J