Open Stack

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:
> >
> >   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.


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?


>
> 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.

>
> 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
>



-- 
Juan Antonio Osorio R.
e-mail: jaosorior at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151119/b788ae3e/attachment.html>