https://etherpad.openstack.org/p/mitaka-heat-composition-improvements Looking to clarify objections to the proposal to enhance HOT to support an optional capabilities annotation,
which is similar in concept to the TOSCA substitution_mapping definition.
This would move us closer to being a TOSCA capable orchestrator, and enable more control of the already
powerful composition capabilities exposed via our resource_registry interfaces.
Spec:
https://review.openstack.org/#/c/196656/ This then raises some interesting questions around parameter interfaces (and resource_registry interfaces)
If you expect to have your heat templates widely consumed, the parameters inteface is effectively your "public API".
* How do you deprecate or rename anything, ever (we need a user-visible warning mechanism, combined with some sort of deprecated tag similar to how oslo config deprecation works?)
* Could we add some way to define cross parameter constraints (or multiple conflicting parameter_groups), such that you could e.g group certain parameters as deprecated and/or conflicting with some others?
* Related to the cross-parameter constraint but more general than deprecation/conflict, could we have e.g defaults defined derived from another parameter, or constraints (such as min/max) derived in a similar way?
The idea with all of this is to enable a more complete user-visible schema to be defined, and to enable that to evolve over time when those writing and consuming the templates are not the same folks.
