Custom "Provider" Resource Based on Nested Stack
From: http://
* Create a Custom resource type that is based on a nested stack but, unlike the AWS::CloudForma
* 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:
- 2013.2
- Started by
- Randall Burt
- Completed by
- Randall Burt
Related branches
Related bugs
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://
http://
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:
https:/
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 "CustomProvider
(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:/
Addressed by: https:/
Add a Fn::Split function to aid provider templates
Addressed by: https:/
Initial provider templates
Addressed by: https:/
Handle conversion of MAP properties to JSON params
Addressed by: https:/
Do not override FnGetAtt
Addressed by: https:/
Allow template resource use outside of Environment
Addressed by: https:/
Fix punctuation in heat/tests/
Work Items
Dependency tree
* Blueprints in grey have been implemented.