Show user progress of deployed service

[Antonio Rosales]

A large issue we keep hearing from users is they have no visibility into what is happening after they issue a deploy. I understand at this point Juju is at the mercy of the cloud provider API. However, I think we can still improve the story here. Some suggestions are to output a human readable message stating something to the effect, "Virtual Machine is being spun on up on Cloud X, this may take a few minutes pending provider bandwidth."

< brainstorm > Given you don't want to block the command line while the state goes from pending to started it would also be nice to have juju status know the average time it takes to deploy a service on a given cloud and then compare that to the current state and output a progress meter/message/percent/something. If we want to leave the agent-state field alone perhaps adding a agent-state-progress that we document to be a best guess with an accompanying command line that just return service state progress info. </brainstorm>

Other ideas welcome on how we can improve telling users what is going on from issuing a deploy to the agent-state=started. I'll need to check with the GUI team on how they set up their progress bar when they deploy services.

-thanks,
Antonio

[John A Meinel (jameinel)]

I think this fits in with the "first 30 minutes" experience that we want to focus on.

[Dave Cheney (dave-cheney)]

I am wary of using any sort of heuristics to 'guess' how the provider is
performing.

How about a new flag, `-w` which will cause any commands which will
allocate or create machines to wait until the service reaches started/error
state ?

On Sat, Aug 17, 2013 at 4:27 PM, John A Meinel <email address hidden>wrote:

> I think this fits in with the "first 30 minutes" experience that we want
> to focus on.
>
>
> ** Changed in: juju-core
> Importance: Undecided => High
>
> ** Changed in: juju-core
> Status: New => Triaged
>
> ** Tags added: ui
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> Matching subscriptions: MOAR JUJU SPAM!
> https://bugs.launchpad.net/bugs/1213186
>
> Title:
> Show user progress of deployed service
>
> Status in juju-core:
> Triaged
>
> Bug description:
> A large issue we keep hearing from users is they have no visibility
> into what is happening after the issue a deploy. I understand at this
> point Juju is at the mercy of the cloud provider API. However, I think
> we can still improve the story here. Some suggestions are to output a
> human readable message stating something to the effect, "Virtual
> Machine is being spun on up on Cloud X, this may take a few minutes
> pending provider bandwidth."
>
> < brainstorm > Given you don't want to block the command line while
> the state goes from pending to started it would also be nice to have
> juju status know the average time it takes to deploy a service on a
> given cloud and then compare that to the current state and output a
> progress meter/message/percent/something. If we want to leave the
> agent-state field alone perhaps adding a agent-state-progress that we
> document to be a best guess with an accompanying command line that
> just return service state progress info. </brainstorm>
>
> Other ideas welcome on how we can improve telling users what is going
> on from issuing a deploy to the agent-state=started. I'll need to
> check with the GUI team on how they set up their progress bar when
> they deploy services.
>
> -thanks,
> Antonio
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1213186/+subscriptions
>

[Dave Cheney (dave-cheney)]

I am wary of using any sort of heuristics to 'guess' how the provider is
performing.

How about a new flag, `-w` which will cause any commands which will
allocate or create machines to wait until the service reaches started/error
state ?

On Sat, Aug 17, 2013 at 8:07 PM, David Cheney <email address hidden>wrote:

> I am wary of using any sort of heuristics to 'guess' how the provider is
> performing.
>
> How about a new flag, `-w` which will cause any commands which will
> allocate or create machines to wait until the service reaches started/error
> state ?
>
>
> On Sat, Aug 17, 2013 at 4:27 PM, John A Meinel <email address hidden>wrote:
>
>> I think this fits in with the "first 30 minutes" experience that we want
>> to focus on.
>>
>>
>> ** Changed in: juju-core
>> Importance: Undecided => High
>>
>> ** Changed in: juju-core
>> Status: New => Triaged
>>
>> ** Tags added: ui
>>
>> --
>> You received this bug notification because you are subscribed to juju-
>> core.
>> Matching subscriptions: MOAR JUJU SPAM!
>> https://bugs.launchpad.net/bugs/1213186
>>
>> Title:
>> Show user progress of deployed service
>>
>> Status in juju-core:
>> Triaged
>>
>> Bug description:
>> A large issue we keep hearing from users is they have no visibility
>> into what is happening after the issue a deploy. I understand at this
>> point Juju is at the mercy of the cloud provider API. However, I think
>> we can still improve the story here. Some suggestions are to output a
>> human readable message stating something to the effect, "Virtual
>> Machine is being spun on up on Cloud X, this may take a few minutes
>> pending provider bandwidth."
>>
>> < brainstorm > Given you don't want to block the command line while
>> the state goes from pending to started it would also be nice to have
>> juju status know the average time it takes to deploy a service on a
>> given cloud and then compare that to the current state and output a
>> progress meter/message/percent/something. If we want to leave the
>> agent-state field alone perhaps adding a agent-state-progress that we
>> document to be a best guess with an accompanying command line that
>> just return service state progress info. </brainstorm>
>>
>> Other ideas welcome on how we can improve telling users what is going
>> on from issuing a deploy to the agent-state=started. I'll need to
>> check with the GUI team on how they set up their progress bar when
>> they deploy services.
>>
>> -thanks,
>> Antonio
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/juju-core/+bug/1213186/+subscriptions
>>
>
>

[Antonio Rosales (arosales)]

Dave,
Thanks for the reply.

A -w option would help, but still lacks in helping the user identify how long they should be waiting. I completely agree my earlier suggestion is a guess, but at this point a guess may be better than nothing, or perhaps there is an unexplored option. I just feel like the story can be improved here.

-thanks,
Antonio

[Anastasia (anastasia-macmood)]

Re-targeting for Juju 2.x

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.