[Openstack] [Heat] Stack Lifetime, Signaling, and AutoScaling Groups
Zane Bitter
zbitter at redhat.com
Tue Jun 17 16:33:16 UTC 2014
On 17/06/14 11:41, Joe D'Andrea wrote:
> Greetings! I am new to OpenStack and have a few questions:
Welcome :)
> 1. Is the "Walk-through in a stack's lifetime" section of this Wiki page accurate as of Icehouse? If not, what has changed?
>
> https://wiki.openstack.org/wiki/Heat/ApplicationDeployment
Yep, that is still accurate as far as it goes.
> 2. Related to #1, going forward, is it recommended to move off cfn-tools and on to cloud-init?
You're using cloud-init either way. If cfn-tools does what you need then
there is probably no reason to change - the user-data script is
arbitrary, so you can write whatever script works for you. However,
stuff like Software Deployments + golden images can be a better
alternative to the user-data script.
> 3. With Software Config/Deployment being bona fide resources, I imagine completion is signaled just like any other resource.
Every resource is different. Configs are easy of course, but Deployments
signal using something very similar to a WaitCondition under the hood
(with the advantage that you don't have to see how the sausage is made).
> If I understand correctly, resources signal via RPC (yes?).
No.
> Do software deployment resources work the same way under the hood (in particular between the VM and Nova)?
They work the same way as WaitConditions - a ReST API call back to Heat
to indicate completion.
> 4. Given a stack with a server resource, suppose a template update moves this resource into an AutoScaling Group (same resource name). Is the resource ostensibly left as-is or is this always a destructive operation? Also, is this true for *any* resource placed into such a group during an update?
There is no concept of "moving" a resource into a scaling group. In
fact, there is no concept in general of changing the type of a resource
and still considering it in any sense the 'same' resource; it should
always be replaced. (The only guarantee provided is that if resources
have the same name, the new one will be created before the old one is
deleted.)
> I ask because it looks like AutoScaling invokes a nested call to Heat, passing along all the resources under its purview. I'm unsure how that nesting is handled in the case of updates and upstream resources, especially if the nested stack has its own ID (tracked, I imagine, as part of an AutoScaling Group).
Autoscaling maintains a generated template for the nested stack, so an
update just does a nested stack update call on the nested stack with the
current template.
cheers,
Zane.
More information about the Openstack
mailing list