Bug 1042221

Summary:	[RFE][heat]: Create a stack by adopting existing resources
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	openstack-heat	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	high
Version:	unspecified	CC:	markmc, mlopes, sbaker, sdake, shardy, yeylon
Target Milestone:	ga	Keywords:	FutureFeature
Target Release:	5.0 (RHEL 7)
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/heat/+spec/adopt-stack
Whiteboard:	upstream_milestone_icehouse-3 upstream_status_implemented upstream_definition_approved
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	This enhancement adds 'stack-adopt', which allows Orchestration (heat) to manage existing resources as a complete stack. As a result, Orchestration is able to manage resources that were present prior to Orchestration's deployment.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-07-22 19:08:57 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description RHOS Integration 2013-12-12 21:24:20 UTC

Cloned from launchpad blueprint https://blueprints.launchpad.net/heat/+spec/adopt-stack.

Description:

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.

Specification URL (additional information):

None