Open Stack

On 17/03/14 21:18, Mike Spreitzer wrote:
> Zane Bitter <zbitter at redhat.com> wrote on 03/17/2014 07:03:25 PM:
>
>  > On 17/03/14 17:03, Ton Ngo wrote:
>
>  > > - How to handle resources with timer, e.g. wait condition:
>   pause/resume
>  > > timer value
>  >
>  > Handle it by only allowing pauses before and after. In most cases I'm
>  > not sure what it would mean to pause _during_.
>
> I'm not sure I follow this part.  If at some time a timer is started,
> and the event(s) upon which it is waiting are delayed by hitting a
> breakpoint and waiting for human interaction --- I think this is the
> scenario that concerned Ton.  It seems to me the right answer is that
> all "downstream" timers have to stop ticking between break and resume.

Perhaps this was too general. To be specific, there is exactly one 
resource with a timer* - a WaitCondition. A WaitCondition is usually 
configured to be dependent on the server that should trigger it. Nothing 
interesting happens while a WaitCondition is waiting, so there is no 
point allowing a break point in the middle. You would either set the 
breakpoint after the server has completed or before the WaitCondition 
starts (which amount to the same thing, assuming no other dependencies). 
You could, in theory, set a breakpoint after the WaitCondition complete, 
though the use case for that is less obvious. In any event, at no time 
is the stack paused _while_ the WaitCondition is running, and therefore 
no need to use anything but wallclock time to determine the timeout.

cheers,
Zane.

* Technically there is another: autoscaling groups during update with an 
UpdatePolicy specified... however these use a nested stack, and the 
solution here is to use this same feature within the nested stack to 
implement the delays rather than complicate things in the stack 
containing the autoscaling group resource.