Open Stack

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