RFC feature planning - robust instance launching

Jan Provazník jprovazn at redhat.com
Fri Mar 30 08:25:21 UTC 2012


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



More information about the aeolus-devel mailing list