This spec covers the implementation of a uniform signaling framework for heat resources.
The standard way to signal a resource is to do it through a request to heat-api. This works well for user generated signals, but it is often the case that signals are not generated directly by the user, but instead are triggered by a resource or a service when certain conditions are met. The difficulty in triggering these internal signals is that the user credentials are not available, so heat resources implement a variety of mechanisms to make signals work in this context.
For example, the OS::Heat::ScalingPolicy resource exposes a alarm_url attribute that is a EC2 signed URL, so the heat-api-cfn compatibility service must be available for these signals to work. The OS::Heat::WaitConditionHandle resource, on the other side, exposes a proper endpoint to heat-api and a token to authenticate against it, but that only allows signals to be sent before the token expires. Unfortunately there is no way to renew the token, so these resources cannot be used for long tasks. Other heat resources use swift temp URLs as signals, and yet some others expose a more traditional set of heat-owned keystone credentials that can be used to obtain a token to authenticate against heat-api.
Out of all these authentication methods, the only one that is implemented in a base class accessible to all resources is EC2 signed URLs, the ones that are based on a heat-api-cfn endpoint. The others are implemented as “one-offs” by individual resources, making them hard to implement across resources without code duplication.
The heat-engine service includes a SignalResponder base class, from which resources that can be signaled can inherit. To make the different types of signals available to all resources, their implementations will be moved to this class, which already contains the support for EC2 signed URLs.
With support for using all the different types of signals implemented in SignalResponder, resources will be able to offer different choices of signals, without having to deal with the particulars of each implementation.
Resources will have the option to expose a single signal type, or else implement a signal_transport property that gives the operator the option to select the signal type.
The credentials necessary to trigger a signal will be exposed in the resource as an attribute called signal, of type map. The items included in the map will depend on the selected signal type.
The following signal types will be supported:
Implement a webhook solution similar to EC2 signed URLs based on a heat-api endpoint. This is a less flexible approach, and it has the drawback that the authentication tokens are embedded in URLs, which are typically written to logfiles. The nice thing about the proposed solution is that nothing prevents a webhook signal to be added to the list of signal options in the future.