Open Stack

On Thu, Nov 19, 2015 at 06:50:35PM +0200, Juan Antonio Osorio wrote:
>    On Thu, Nov 19, 2015 at 6:16 PM, Steven Hardy <shardy at redhat.com> wrote:
> 
>      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:
>      >
>      >A  A 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.
> 
>    A 
>    I guess the TLS patch falls into this category. I would say that this
>    needs to be
>    documented somewhere though. So if there are parameters that would be
>    available via parameter defaults, then that should be visible somewhere.
>    Is there any preferred place to add such a thing?

So far, we've just been documenting them via example environment files,
such as you have done e.g in environments/enable-tls.yaml

The problem with this is it's not something that's easily discoverable by
any user/UI, the values in the example aren't necessarily exhaustive, and
it's not convenient to have heat validate example environments like this,
because they typically contain dummy values the user must know to modify.

There is work going on to build a schema around these example environments:

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

But even with that in place, it doesn't provide a convenient interface for
the "common to most deployments" type options most deployers will want to
be exposed to.

>      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 sounds reasonable. Though the same question as above applies.

Same as above, example environments is all we have right now.

Steve