Open Stack

The notify/callback mechanism seems like a good solution.  This should
enable creating a high level debugger for different DSL (HOT, Tosca, ...),
running as a separate process.  The debugger would attach to a stack,
present a logical model to the user and interact with the Heat engine.
This would be similar to the typical program debugger.   This mechanism
should also allow integrating with a process engine to handle human
interaction.

About the resource with timer, I was not sure if there are other resources
beside WaitCondition that contains a timer, so it's good to know that
currently only WaitCondition falls into this category.  My concern was the
scenario when the timer might get kicked off and then a resource that
should interact with the timer hits a breakpoint, but Zane's point is that
this is not possible for WaitCondition since there is supposed to be a
dependency on the resource.  Then to debug the scenario "why did my
WaitCondition fails", the user would set a breakpoint before the
WaitCondition, or after any of the resources that the WaitCondition depends
on.   In this case, we would know that the timer will never get kicked off
because of the dependency.

Ton Ngo,



From:	Zane Bitter <zbitter at redhat.com>
To:	openstack-dev at lists.openstack.org,
Date:	03/18/2014 09:45 AM
Subject:	Re: [openstack-dev] [Heat] Stack breakpoint



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.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev