Hi Clint,
Thanks for the reply! I'll update the bug you raised with more
information. In the meantime, I agree with you that cfn-hup is enough
for now.
BTW, is there any bug or missing feature that would prevent me from
replacing cfn-hup by os-collect-config?
Simon
Le 20/09/2013 22:12, Clint Byrum a écrit :
Excerpts from Simon Pasquier's message of 2013-09-17 05:57:58 -0700:
Hello,
I'm testing stack updates with instance group and wait conditions and
I'd like to get feedback from the Heat community.
My template declares an instance group resource with size = N and a wait
condition resource with count = N (N being passed as a parameter of the
template). Each group's instance is calling cfn-signal (with a different
id!) at the end of the user data script and my stack creates with no error.
Now when I update my stack to run N+X instances, the instance group gets
updated with size=N+X but since the wait condition is deleted and
recreated, the count value should either be updated to X or my existing
instances should re-execute cfn-signal.
That is a bug, the count should be something that can be updated in-place.
https://bugs.launchpad.net/heat/+bug/1228362
Once that is fixed, there will be an odd interaction between the groups
though. Any new instances will add to the count, but removed instances
will not decrease it. I'm not sure how to deal with that particular quirk.
That said, rolling updates will likely produce some changes to the way
updates interact with wait conditions so that we can let instances and/or
monitoring systems feed back when an instance is ready. That will also
help deal with the problem you are seeing.
In the mean time, cfn-hup is exactly what you want, and I see no problem
with re-running cfn-signal after an update to signal that the update
has applied.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Simon Pasquier
Software Engineer
Bull, Architect of an Open World
Phone: + 33 4 76 29 71 49
http://www.bull.com
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
