<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 19, 2015 at 6:16 PM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Nov 16, 2015 at 08:15:48PM +0100, Giulio Fidente wrote:<br>
> On 11/16/2015 04:25 PM, Steven Hardy wrote:<br>
> >Hi all,<br>
> ><br>
> >I wanted to start some discussion re $subject, because it's been apparrent<br>
> >that we have a lack of clarity on this issue (and have done ever since we<br>
> >started using parameter_defaults).<br>
><br>
> [...]<br>
><br>
> >How do people feel about this example, and others like it, where we're<br>
> >enabling common, but not mandatory functionality?<br>
><br>
> At first I was thinking about something as simple as: "don't use top-level<br>
> params for resources which the registry doesn't enable by default".<br>
><br>
> It seems to be somewhat what we tried to do with the existing pluggable<br>
> resources.<br>
><br>
> Also, not to hijack the thread but I wanted to add another question related<br>
> to a similar issue:<br>
><br>
>   Is there a reason to prefer use of parameters: instead of<br>
> parameter_defaults: in the environment files?<br>
><br>
> It looks to me that by defaulting to parameter_defaults: users won't need to<br>
> update their environment files in case the parameter is moved from top-level<br>
> into a specific nested stack so I'm inclined to prefer this. Are there<br>
> reasons not to?<br>
<br>
</span>The main reason is scope - if you use "parameters", you know the data flow<br>
happens via the parent template (e.g overcloud-without-mergepy) and you<br>
never have to worry about naming collisions outside of that template.<br>
<br>
But if you use parameter_defaults, all parameters values defined that way<br>
are effectively global, and you then have to be much more careful that you<br>
never shadow a parameter name and get an unexpected value passed in to it.<br>
<br>
Here's another example of why we need to decide this btw:<br>
<br>
<a href="https://review.openstack.org/#/c/229471/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/229471/</a><br>
<br>
Here, we have some workers parameters, going only into controller.yaml -<br>
this is fine, but the new options are completely invisible to users who<br>
look at the overcloud_without_mergepy parameters schema as their interface<br>
(in particular I'm thinking of any UI here).<br>
<br>
My personal preference is to say:<br>
<br>
1. Any templates which are included in the default environment (e.g<br>
overcloud-resource-registry-puppet.yaml), must expose their parameters<br>
via overcloud-without-mergepy.yaml<br>
<br>
2. Any templates which are included in the default environment, but via a<br>
"noop" implementation *may* expose their parameters provided they are<br>
common and not implementation/vendor specific.</blockquote><div> </div><div>I guess the TLS patch falls into this category. I would say that this needs to be<br></div><div>documented somewhere though. So if there are parameters that would be<br></div><div>available via parameter defaults, then that should be visible somewhere.<br></div><div>Is there any preferred place to add such a thing?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. Any templates exposing vendor specific interfaces (e.g at least anything<br>
related to the OS::TripleO::*ExtraConfig* interfaces) must not expose any<br>
parameters via the top level template.<br>
<br>
How does this sound?<br></blockquote><div><br></div><div>This sounds reasonable. Though the same question as above applies. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This does mean we suffer some template bloat from (1) and (2), but it makes<br>
the job of any UI or other tool requiring user input much easier, I think?<br>
<br>
Steve<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2">Juan Antonio Osorio R.<br>e-mail: <a href="mailto:jaosorior@gmail.com" target="_blank">jaosorior@gmail.com</a><br></font><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2"><br></font></div></div></div>
</div></div>