Bug 1042257 - [RFE][heat]: Implement native (non ec2token) method for SignalResponder signals
Summary: [RFE][heat]: Implement native (non ec2token) method for SignalResponder signals
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/heat...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 21:32 UTC by RHOS Integration
Modified: 2016-02-08 17:23 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 17:29:19 UTC
Target Upstream Version:

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

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
Note You need to log in before you can comment on or make changes to this bug.