Create a stack by adopting existing resources

Registered by Steve Baker

This will allow a stack to be created without creating any resources. Instead the state of some existing resources will be passed in to the adopt action. Partnered with blueprint abandon-stack this will allow stacks to be moved from one heat instance to another.

Possible use cases for abandon/adopt are:
* Moving a stack from a private heat orchestrating on a public cloud to the public heat
* Rebalancing a sharded heat
* Moving stacks off a heat that needs an offline upgrade

It also may be possible to hand-craft the resource state so that an adopt can happen on resources which were not previously created with heat.

A Resource.handle_adopt method will do the following:
* set the supplied resource id
* set the supplied resource data
* set the supplied metadata(?) if different from the template

Some resource subclasses may need to implement their own handle_adopt, but hopefully this will be rare.

Consideration needs to be given to configured endpoints/signal urls on running compute resources, which may stop working when the stack is moved from one heat to another. Ideally existing compute resource will reconfigure themselves for new endpoints.

Blueprint information

Steve Baker
Steve Baker
Vijendar Komalla
Series goal:
Accepted for icehouse
Milestone target:
milestone icon 2014.1
Started by
Vijendar Komalla
Completed by
Vijendar Komalla

Related branches



Edmond Troche: Hi Steve, I was about to create a new BP for a scenario that may be related to this one. The idea is for a template to be able to reference resources in a existing stack (deployed by Heat). For example, lets say we have a stack deployed for just a database server, and this server is capable enough to support hosting of multiple applications that require a database (e.g. WordPress, SugarCRM, etc), we should be able to create a template that has a reference to resources in a running stack. That's the general idea. What do you think, should this go into a separate BP?

stevebaker: Edmond, this can be done now just by passing in the uuid of the resource as a template parameter. Having two stacks actually manage the same resource could result in them conflicting over the resource state (split brain). If what you want to do cannot be done by passing in a uuid parameter, then the solution may be to write finer-grained resources which only manage a small part of the underlying resource (eg, as we're planning to do with the new OS::Neutron:Route resource in )

Gerrit topic:,topic:bp/adopt-stack,n,z

Addressed by:
    Implement adopt-stack

Addressed by:
    Implement adopt-stack

Addressed by:
    Implement adopt-stack for nested stacks


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.