Bug 1042257

Summary:	[RFE][heat]: Implement native (non ec2token) method for SignalResponder signals
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	RFEs	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	markmc, yeylon
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/heat/+spec/native-waitcondition
Whiteboard:	upstream_milestone_none upstream_status_implemented upstream_definition_approved
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-19 17:29:19 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:32:31 UTC

Cloned from launchpad blueprint https://blueprints.launchpad.net/heat/+spec/native-waitcondition.

Description:

The SignalResponder resources (e.g WaitConditionHandle) currently depend on pre-signed URLs which use the keystone ec2tokens API.  We should provide an alternative method which uses either a trust-scoped-token, or a credential derived from a trust.  

A first step would be to implement a native waitcondition resource, where the signal is sent via a curl call, the resource could just provide a string containing the curl command, which would include the trust token in the headers.  Expiring tokens are not an issue for WaitConditions, since the default expiry time of a keystone token is longer than the maximum permissible WaitCondition time.

Specification URL (additional information):

None

Comment 2 Stephen Gordon 2014-02-06 14:08:25 UTC

Updating based on BP milestone