Custom "Provider" Resource Based on Nested Stack

Registered by Steven Hardy


* Create a Custom resource type that is based on a nested stack but, unlike the AWS::CloudFormation::Stack type, has properties and attributes inferred from the parameters and outputs (respectively) of the template provided.

* Modify resource instantiation to create a Custom resource whenever a
resource has a non-empty "Provider" attribute

Blueprint information

Steven Hardy
Randall Burt
Series goal:
Accepted for havana
Milestone target:
milestone icon 2013.2
Started by
Randall Burt
Completed by
Randall Burt

Related branches



The CustomResource type would be a form of StackResource with its Properties and attributes schemata defined dynamically by the template with which it is instantiated. It should also supply the OS::Heat::Metadata &c. pseudo-parameters to the nested stack. The Ref ID should by obtained from the OS::Heat::RefId Output of the stack.

The template would be obtained from a URL specified in the "Provider" field of the resource.

Resource class selection occurs in Resource.__new__ method. This will change to always return a CustomResource when the Provider field contains a URL.

(asalkeld) just ran into this today (aws custom resource):

Might be better calling this something else, UserResource? Not stressed on the exact name
just saying CustomResource might be good for a rest based resource.

(thomas-spatzier) In a template, I think we would never call out type CustomResource (or whatever), but for example something like my::own::resourcetype. Then the implementation would try to find the provider (might be a nested template) according to what is discussed here:

If I am getting this right, seems like the naming question asalkeld raised is about naming the implementation of this resource that does the lookup, right? What about "CustomProviderResource" (hm, not really inventive ...)? Or should we care about it all since it's internal implementation and does not surface in templates?

(randall-burt) @thomas-spatzier: The latest change (should be up shortly) does away with the
naming. To use a template as a resource, one simply specifies the "Type" of the resource
as a uri to the template that implements it. This seems clean, un-ambiguous, and in-line with how
environments work using the same resource.

Gerrit topic:,topic:bp/provider-resource,n,z

Addressed by:
    Add a Fn::Split function to aid provider templates

Addressed by:
    Initial provider templates

Addressed by:
    Handle conversion of MAP properties to JSON params

Addressed by:
    Do not override FnGetAtt

Addressed by:
    Allow template resource use outside of Environment

Addressed by:
    Fix punctuation in heat/tests/templates/README


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.