Back To Schedule
Thursday, October 29 • 11:00am - 11:40am
Heat: Composition improvements

Sign up or log in to save this to your schedule, view media, leave feedback and see who's attending!


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.

Thursday October 29, 2015 11:00am - 11:40am JST
Ohka room
  • format json

Attendees (0)