Hi all, Lately I've been giving some thought to how we might enable easier composability, and in particular how we can make it easier for folks to plug in deeply nested optional extra logic, then pass data in via parameter_defaults to that nested template.
Here's an example of the use-case I'm describing: https://review.openstack.org/#/c/193143/5/environments/cinder-netapp-config.yaml Here, we want to allow someone to easily turn on an optional configuration or feature, in this case a netapp backend for cinder. The parameters specific to this feature/configuration only exist in the nested cinder-netapp-config.yaml template, then parameter_defaults are used to wire in the implementation specific data without having to pass the values through every parent template (potentially multiple layers of nesting). This approach is working out OK, but we're missing an interface which makes the schema for parameters over the whole tree available. This is obviously a problem, particularly for UI's, where you really need a clearly defined interface for what data is required, what type it is, and what valid values may be chosen. I'm considering an optional additional flag to our template-validate API which allows recursive validation of a tree of templates, with the data returned on success to include a tree of parameters, e.g: heat template-validate -f parent.yaml -e env.yaml --show-nested { "Description": "The Parent", "Parameters": { "ParentConfig": { "Default": [], "Type": "Json", "NoEcho": "false", "Description": "", "Label": "ExtraConfig" }, "ControllerFlavor": { "Type": "String", "NoEcho": "false", "Description": "", "Label": "ControllerFlavor" } } "NestedParameters": { "child.yaml": { "Parameters": { "ChildConfig": { "Default": [], "Type": "Json", "NoEcho": "false", "Description": "", "Label": "Child ExtraConfig" } } } } This implies that we also need to pass the "files" map to the validate API, like we currently do for create (we already pass the environment, although it's not really doing much beyond providing parameters for the parent stack AFAICT, we completely skip validating TemplateResources because the files aren't passed): https://github.com/openstack/heat/blob/master/heat/engine/service.py#L873 Before I go ahead and spend time writing a spec/code for this, what do folks think about enhancing validate like this? Is there an alternative, for example adding a parameters schema output to stack-preview? Also interested in TripleO feedback on this, particularly to what extent do we think this could potentially replace some of the template introspection currently done via Tuskar? Thanks, Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
