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 <zbit...@redhat.com> To: openstack-dev@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 <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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev