Loading…
Thursday, October 29 • 11:00am - 11:40am
Heat: Composition improvements

Sign up or log in to save this to your schedule and see who's attending!

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.

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

Attendees (0)