Awesome, thanks for the update! I tried the changes listed here:
https://review.opendev.org/c/openstack/heat/+/915209/1/heat/engine/resources...
This allows for stack updates, but all resources are replaced, not just the waitconditionhandle. This is with a nested stack. Essentially, the servers in the nested stack are wiped out, then rolling updates commence which is not the ideal behaviour. Any suggestions on a fix?
Regards,
Devin
On Wed, Mar 20, 2024 at 8:56 PM Takashi Kajinami kajinamit@oss.nttdata.com wrote:
I could reproduce the problem easily and it seems this is a bug which was added long ago during the effort to introduce convergence (eg. [1]) ...
I reported a bug[2] and submitted a fix[3]. I'll attempt to backport it to active stable branches (till zed).
A potential immediate workaround may be creating a stack with WaitConditionaHandle instead, but mark the resource unhealthy before updating the stack, so that the resource is replaced during the update process.
[1] https://review.opendev.org/c/openstack/heat/+/486267 [2] https://storyboard.openstack.org/#!/story/2011068 [3] https://review.opendev.org/c/openstack/heat/+/913855
On 3/20/24 21:56, Devin Patterson wrote:
Hello,
We are creating a workflow to use Heat auto-scaling groups with wait conditions. The ideal goal would be to have the wait condition clear and require another signal when the Heat stack is updated. Trying to use the resource OS::Heat::UpdateWaitConditionHandle instead of OS::Heat::WaitConditionHandle. This works during initial creation, but when I udpdate the stack with a new configuration, I get the following error.
UpdateWaitConditionHandle.update() got an unexpected keyword argument 'new_template_id'
Any ideas on how to use wait conditions during stack updates or to fix the above error. Thanks in advance.
Devin