Open Stack

On Mon, Nov 16, 2015 at 08:15:48PM +0100, Giulio Fidente wrote:
> On 11/16/2015 04:25 PM, Steven Hardy wrote:
> >Hi all,
> >
> >I wanted to start some discussion re $subject, because it's been apparrent
> >that we have a lack of clarity on this issue (and have done ever since we
> >started using parameter_defaults).
> 
> [...]
> 
> >How do people feel about this example, and others like it, where we're
> >enabling common, but not mandatory functionality?
> 
> At first I was thinking about something as simple as: "don't use top-level
> params for resources which the registry doesn't enable by default".
> 
> It seems to be somewhat what we tried to do with the existing pluggable
> resources.
> 
> Also, not to hijack the thread but I wanted to add another question related
> to a similar issue:
> 
>   Is there a reason to prefer use of parameters: instead of
> parameter_defaults: in the environment files?
> 
> It looks to me that by defaulting to parameter_defaults: users won't need to
> update their environment files in case the parameter is moved from top-level
> into a specific nested stack so I'm inclined to prefer this. Are there
> reasons not to?

The main reason is scope - if you use "parameters", you know the data flow
happens via the parent template (e.g overcloud-without-mergepy) and you
never have to worry about naming collisions outside of that template.

But if you use parameter_defaults, all parameters values defined that way
are effectively global, and you then have to be much more careful that you
never shadow a parameter name and get an unexpected value passed in to it.

Here's another example of why we need to decide this btw:

https://review.openstack.org/#/c/229471/

Here, we have some workers parameters, going only into controller.yaml -
this is fine, but the new options are completely invisible to users who
look at the overcloud_without_mergepy parameters schema as their interface
(in particular I'm thinking of any UI here).

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.

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