Create a stack by adopting existing resources
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.
* 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
- Status:
- Complete
- Approver:
- Steve Baker
- Priority:
- Medium
- Drafter:
- Steve Baker
- Direction:
- Approved
- Assignee:
- Vijendar Komalla
- Definition:
- Approved
- Series goal:
- Accepted for icehouse
- Implementation:
-
Implemented
- Milestone target:
-
2014.1
- Started by
- Vijendar Komalla
- Completed by
- Vijendar Komalla
Related branches
Related bugs
Sprints
Whiteboard
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 https:/
Gerrit topic: https:/
Addressed by: https:/
Implement adopt-stack
Addressed by: https:/
Implement adopt-stack
Addressed by: https:/
Implement adopt-stack for nested stacks
Work Items
Dependency tree
* Blueprints in grey have been implemented.
