Open Stack

> My personal preference is to say:
>
> 1. Any templates which are included in the default environment (e.g
> overcloud-resource-registry-puppet.yaml), must expose their parameters
> via overcloud-without-mergepy.yaml
>
> 2. Any templates which are included in the default environment, but via a
> "noop" implementation *may* expose their parameters provided they are
> common and not implementation/vendor specific.

I think this makes sense. Two combination of these two represent what 
TripleO views as the common* API for deploying.

* "common" in the sense that you may not use all of them every time, but 
they are part of the expected deployments.

I still have concerns with us not treating this strongly enough as a 
versioned API, but we can discuss that in a different thread. That's 
more of a "when" we change the parameters v. the conventions on "how" we 
do it.

> 3. Any templates exposing vendor specific interfaces (e.g at least anything
> related to the OS::TripleO::*ExtraConfig* interfaces) must not expose any
> parameters via the top level template.
>
> How does this sound?
>
> This does mean we suffer some template bloat from (1) and (2), but it makes
> the job of any UI or other tool requiring user input much easier, I think?
>
> Steve
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>