Add interface type contracts to Heat
Currently Heat allows to compose stack out of independent templates via provider resource / environment + resource_registry. While this approach works fine for human it doesn't allow automated tool to infer list of templates/resources that are compatible with resource consumer expectations.
To solve this it is proposed to introduce concept of interface with the following properties:
1. There is a syntax to declare interface type describing its inputs/outputs
2. Interface declarations need to be published and have unique identifier (unique type name) so that they could be unambiguously referenced by all interface implementors
3. HOT templates need to be able to claim their conformance to interfaces (explicitly say they implement interface)
4. This claim need to be verified on all levels. One cannot claim to implement interface if it doesn't have all required inputs/outputs. Major change to interface declaration must break all implementors.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Stan Lagun
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- New
- Series goal:
- None
- Implementation:
- Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
As far as I can tell, only 3 and 4 are new and 4 is only true for template-based resources.
Actually the big problem that is not addressed by this blueprint is that usually interfaces are used for consumption. So that templates could have parameters of interface type (rather than String/Number). If interfaces are intended for instantiation of resource it must cover 100% of its inputs/outputs. Thus there cannot be interfaces inheritance neither template inheritance. Resources couldn't implement more than one interface if they are not 100% equal. Normally interfaces specify minimum required contract required by consumer rather than maximum as in this design. This allows having implementations with additional parameters while still conforming to the same interface
There is also a concern regarding 2 regarding if it is possible to have interface declarations shared across different tenants