On 03/29/2012 02:33 PM, Angus Thomas wrote:
On 03/27/2012 10:18 PM, Matt Wagner wrote:
>> > launch progress page (TBD)
>> > Angus suggested that there could be something like “launch progress
>> > page” where details of what’s being done w/ deployment would be
>> > showed. So if the user checks “show me details” checkbox before
>> > clicking “launch” button, he is redirected to this progress page
>> > where info which step is being done is displayed:
>> > "Selecting provider account... account_name"
>> > “Making launch request for instance... x”
>> > > This could be probably just displaying of all events associated with
>> > this deployment.
> I like the idea of just showing an event log, rather than trying to
> implement anything over-the-top for this.
>
>
Part of the reason I think we might want the option to see the details
in the UI is that it lets the user get confirmation that something is
actually happening.
There's a danger that, if the user sits and looks an the Conductor UI
for as long as it takes to get a multi-instance deployable launched, and
doesn't get a lot of intermediate feedback they are going to:
- Fear that something has gone wrong
- Blame Conductor for being slow
Whereas, if we give them an optional read-only view of the stages of
selecting a provider, launching and rolling back individual instances
etc., they'll know that something is actually happening, and they're not
waiting for a process which has quietly died, and they'll have a better
sense of where the time is actually being spent.
Agree with reasons above, having some way how to inform a user about
what's being done sounds good. There should always be logged an event
anytime deployment's state is changed.
Question is if a special page is needed for this launch-time events or
if redirection on deployment's show page (where we should
display/autorefresh events anyway) is sufficient?
One important thing which may not be obvious:
following things are done on *foreground* when a user presses launch
button and before he gets any response:
- provider selection
- launch params upload to config server
- deployable's image checking
- launching instances which are not blocked (especially this can take
more time on multi-instance deployments)
This means that we can't show a user any progress on above tasks and he
will see only "loading page" cursor until it's finished. If we want to
make UI not-blocked by above tasks and show users progress on them, it
means doing this tasks on background. This means using some background
solution - delayed_job or similar (but not condor please) or extending
dbomatic significantly. I suggested using some background solution for
launching instances many times but never got positive response.
Taking advantage of the situation: is it a good idea to integrate
background solution for launching instances at this moment and as a part
of this scenario?
Rest of tasks (waiting on running state or doing rollback/relaunch) is
done from dbomatic and progress can be easily displayed with what we
have now.
Jan