<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 21, 2015 at 2:05 AM, Ben Nemec <span dir="ltr"><<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thinking about this some more makes me wonder if we need a sample config<br>
generator like oslo.config.  It would work off something similar to the<br>
capabilities map, where you would say<br>
<br>
SSL:<br>
  templates:<br>
    -puppet/extraconfig/tls/tls-cert-inject.yaml<br>
  output:<br>
    -environments/enable-ssl.yaml<br>
<br>
And the tool would look at that, read all the params from<br>
tls-cert-inject.yaml and generate the sample env file.  We'd have to be<br>
able to do a few new things with the params in order for this to work:<br>
<br>
-Need to specify whether a param is intended to be set as a top-level<br>
param, parameter_defaults (which we informally do today with the Can be<br>
overridden by parameter_defaults comment), or internal, to define params<br>
that shouldn't be exposed in the sample config and are only intended as<br>
an interface between templates.  There wouldn't be any enforcement of<br>
the internal type, but Python relies on convention for its private<br>
members so there's precedent. :-)<br></blockquote><div>Perhaps a convention could be done in a similar fashion to how things are done in<br></div><div>python. Where parameters passed from top-level could be defined as they are defined<br></div><div>now (with camel-case type of definition) and non-top-parameters could be defined with<br></div><div>lowercase and underscores (or with an underscore prefix). That could make things<br></div><div>clearer and allow us to have a more programmatic approach in the future. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-There would have to be some way to pick out only certain params from a<br>
template, since I think there are almost certainly features that are<br>
configured using a subset of say puppet/controller.yaml which obviously<br>
can't just take the params from an entire file.  Although maybe this is<br>
an indication that we could/should refactor the templates to move some<br>
of these optional params into their own separate files (at this point I<br>
think I should take a moment to mention that this is somewhat of a brain<br>
dump, so I haven't thought through all of the implications yet and I'm<br>
not sure it all makes sense).<br>
<br>
The nice thing about generating these programmatically is we would<br>
formalize the interface of the templates somewhat, and it would be<br>
easier to keep sample envs in sync with the actual implementation.<br>
You'd never have to worry about someone adding a param to a file but<br>
forgetting to update the env (or at least it would be easy to catch and<br>
fix when they did, just run "tox -e genconfig").<br></blockquote><div>I think having such a tool is an excellent idea.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'm not saying this is a simple or short-term solution, but I'm curious<br>
what people think about setting this as a longer-term goal, because as I<br>
think our discussion in Tokyo exposed, we're probably going to have a<br>
bit of an explosion of sample envs soon and we're going to need some way<br>
to keep them sane.<br>
<br>
Some more comments inline.<br>
<div><div class="h5"><br>
On 11/19/2015 10:16 AM, Steven Hardy wrote:<br>
> 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>
> 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.<br>
<br>
</div></div>This seems like a reasonable approach, although that "may" still leaves<br>
a lot of room for bikeshedding. ;-)<br>
<br>
It might be good to say that in this case it is "preferred" to use a<br>
top-level param, but if there's a reason not to then it's acceptable to<br>
use parameter_defaults.  An example for the SSL case would be the<br>
certificate path - I specifically do not want that visibly exposed to<br>
the user at this point, so I wouldn't want it added to the top-level<br>
template.  I consider that an implementation detail where if you know<br>
what you're doing you can override it, but otherwise you shouldn't touch it.<br></blockquote><div> </div><div>Well, the cert path, for instance, is not exposed as a top-level parameter for<br></div><div>that reason, and even a warning comment was added to it. But for the SSL<br></div><div>case in general, my reasoning for using parameter_defaults was added as a<br></div><div>comment in the relevant CR <a href="https://review.openstack.org/#/c/231930/">https://review.openstack.org/#/c/231930/</a><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5"><br>
><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>
><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>
><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>
><br>
<br>
<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>