juju command progress ui

[Julian Edwards]

On 28/02/13 13:24, Gustavo Niemeyer wrote:
> On Wed, Feb 27, 2013 at 9:21 PM, Julian Edwards
> <julian.edwards at canonical.com> wrote:
>> Is there any reason why bootstrap should not block?  It's not like you
>> can do anything with that environment until it's finished.
> 
> Bootstrap does block while its task isn't done, and unblocks as soon
> as it is done. That sounds like a good general approach. Artificially
> blocking a command that is actually done creates all kinds of
> problems, and doesn't solve the main one which is we still have to
> block the follow up commands (because a blocking bootstrap command
> *can* fail while in fact it worked).
> 
> 
> gustavo @ http://niemeyer.net
> 

Hello Gustavo,

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.

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

> creates all kinds of problems

Could you enumerate those please?  Perhaps I could make some suggestions
from a fresh perspective.

Cheers
J