Custom "Provider" Resource Based on Nested Stack

Registered by Steven Hardy

From: http://lists.openstack.org/pipermail/openstack-dev/2013-April/007989.html

* 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

Status:
Complete
Approver:
Steven Hardy
Priority:
High
Drafter:
None
Direction:
Approved
Assignee:
Randall Burt
Definition:
Approved
Series goal:
Accepted for havana
Implementation:
Implemented
Milestone target:
milestone icon 2013.2
Started by
Randall Burt
Completed by
Randall Burt

Related branches

Sprints

Whiteboard

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):
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cfn-customresource.html
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/crpg-walkthrough.html

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:
https://wiki.openstack.org/wiki/Heat/Providers

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: https://review.openstack.org/#q,topic:bp/provider-resource,n,z

Addressed by: https://review.openstack.org/33241
    Add a Fn::Split function to aid provider templates

Addressed by: https://review.openstack.org/33038
    Initial provider templates

Addressed by: https://review.openstack.org/36314
    Handle conversion of MAP properties to JSON params

Addressed by: https://review.openstack.org/36323
    Do not override FnGetAtt

Addressed by: https://review.openstack.org/36744
    Allow template resource use outside of Environment

Addressed by: https://review.openstack.org/37106
    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.