Implement native (non ec2token) method for SignalResponder signals

Registered by Steven Hardy

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 native authentication.

A first step would be to implement a native OS::Heat::WaitSignal resource, where the signal is sent via the resources/<resource>/signal ReST API, this could potentially use python-heatclient in-instance, with credentials (token or username/password) derived from stack domain users (ref instance-users blueprint)

Blueprint information

Steve Baker
Steven Hardy
Series goal:
Milestone target:
Started by
Steven Hardy
Completed by
Angus Salkeld

Related branches



(stevebaker) If this lands early enough then SoftwareDeployment could use this for signalling completion

(stevebaker) Maybe this isn't needed now that SoftwareDeployment is a signal responder which stays in an IN_PROGRESS state untill it receives a signal containing the deployment outputs. IE it is essentially a wait condition, but better.

(shardy) I think we still need some way to rid wait condition signalling of the requirement for ec2 keypairs and pre-signed requests, which is what I was hoping to solve with this BP - basically a new SignalResponderNotEc2 base-class which provides a native-auth way of sending the signal. I'm not sure of the best interface, but perhaps even an attribute which gives a curl-compatible string, containing a header with a token in it, and the URL for the signal?

(shardy) Making progress on this, but some issues getting the native signal API working have delayed completion, so this will probably miss FPF by a few days. Feel free to bump to Juno, or we can possibly make an exception to FPF if it's ready before the Feature Freeze.

(shardy) Bumped to future as if we can have SoftwareDeployment handle native auth, then this isn't super urgent and I'd rather concentrate on getting trusts on by default, then revisit this in early Juno.

(jasond) stevebaker suggested that we implement RackspaceWaitConditionHandle using TempURLs in (May 8 5:30 PM). Should we implement the native OpenStack wait condition handle that way? Feel free to assign this blueprint to me. I can start working on it soon.

(jasond) shardy, I created a separate blueprint for the SwiftSignal resource:

Gerrit topic:,topic:bp/native-waitcondition,n,z

Addressed by:
    Convert WaitConditionHandle to use handle_signal

Addressed by:
    Update waitcondition API to use signal RPC interface

Addressed by:
    Refactor waitcondition resources to allow easier subclassing

Addressed by:
    Add an OS::Heat::WaitCondition resource

Gerrit topic:,topic:bp/native-waitcondition2,n,z

Addressed by:
    heat_keystoneclient add get_user_token

Gerrit topic:,topic:bp/native-waitcondition3,n,z

Addressed by:
    Convert WaitConditionHandle to use handle_signal

Gerrit topic:,topic:bp/native-waitcondition4,n,z

Addressed by:
    clients make heat_url public

Addressed by:
    Refactor waitcondition resources to allow easier subclassing

Gerrit topic:,topic:bug/1337772,n,z

Addressed by:
    stack user add _user_token

Addressed by:
    Add native WaitConditionHandle resource

Gerrit topic:,topic:bp/native-waitcondition5,n,z

Gerrit topic:,topic:bp/native-waitcondition6,n,z

Gerrit topic:,topic:bp/native-waitcondition7,n,z

You should not set a milestone target unless the blueprint has been properly prioritized by the project drivers.
(This is an automated message)

Gerrit topic:,topic:bp/native-waitcondition8,n,z

Addressed by:
    Native WaitConditionHandle move to common curl_cli


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.