On 17/03/14 21:18, Mike Spreitzer wrote:
Zane Bitter <zbit...@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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
