Thinking about this some more makes me wonder if we need a sample config
generator like oslo.config. It would work off something similar to the
capabilities map, where you would say
SSL:
templates:
-puppet/extraconfig/tls/tls-cert-inject.yaml
output:
-environments/enable-ssl.yaml
And the tool would look at that, read all the params from
tls-cert-inject.yaml and generate the sample env file. We'd have to be
able to do a few new things with the params in order for this to work:
-Need to specify whether a param is intended to be set as a top-level
param, parameter_defaults (which we informally do today with the Can be
overridden by parameter_defaults comment), or internal, to define params
that shouldn't be exposed in the sample config and are only intended as
an interface between templates. There wouldn't be any enforcement of
the internal type, but Python relies on convention for its private
members so there's precedent. :-)
-There would have to be some way to pick out only certain params from a
template, since I think there are almost certainly features that are
configured using a subset of say puppet/controller.yaml which obviously
can't just take the params from an entire file. Although maybe this is
an indication that we could/should refactor the templates to move some
of these optional params into their own separate files (at this point I
think I should take a moment to mention that this is somewhat of a brain
dump, so I haven't thought through all of the implications yet and I'm
not sure it all makes sense).
The nice thing about generating these programmatically is we would
formalize the interface of the templates somewhat, and it would be
easier to keep sample envs in sync with the actual implementation.
You'd never have to worry about someone adding a param to a file but
forgetting to update the env (or at least it would be easy to catch and
fix when they did, just run "tox -e genconfig").
I'm not saying this is a simple or short-term solution, but I'm curious
what people think about setting this as a longer-term goal, because as I
think our discussion in Tokyo exposed, we're probably going to have a
bit of an explosion of sample envs soon and we're going to need some way
to keep them sane.
Some more comments inline.
On 11/19/2015 10:16 AM, Steven Hardy 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.
This seems like a reasonable approach, although that "may" still leaves
a lot of room for bikeshedding. ;-)
It might be good to say that in this case it is "preferred" to use a
top-level param, but if there's a reason not to then it's acceptable to
use parameter_defaults. An example for the SSL case would be the
certificate path - I specifically do not want that visibly exposed to
the user at this point, so I wouldn't want it added to the top-level
template. I consider that an implementation detail where if you know
what you're doing you can override it, but otherwise you shouldn't touch it.
>
> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
