[openstack-dev] [tripleo] When to use parameters vs parameter_defaults

Ben Nemec openstack at nemebean.com
Tue Nov 24 16:05:59 UTC 2015


On 11/23/2015 01:20 AM, Juan Antonio Osorio wrote:
> 
> 
> On Sat, Nov 21, 2015 at 2:05 AM, Ben Nemec <openstack at nemebean.com
> <mailto:openstack at nemebean.com>> wrote:
> 
>     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. :-)
> 
> Perhaps a convention could be done in a similar fashion to how things
> are done in
> python. Where parameters passed from top-level could be defined as they
> are defined
> now (with camel-case type of definition) and non-top-parameters could be
> defined with
> lowercase and underscores (or with an underscore prefix). That could
> make things
> clearer and allow us to have a more programmatic approach in the future.
> 
>     -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 think having such a tool is an excellent idea.
> 
> 
>     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.
> 
>  
> Well, the cert path, for instance, is not exposed as a top-level
> parameter for
> that reason, and even a warning comment was added to it. But for the SSL
> case in general, my reasoning for using parameter_defaults was added as a
> comment in the relevant CR https://review.openstack.org/#/c/231930/

Right, that's exactly the point I'm trying to make.  I would like our
policy on this to say that it's preferred to use top-level params for
integrated things with a noop implementation, but that exceptions can be
made.  The cert path is such an exception, and I'm good with the rest of
the params being top-level in this case.

> 
> 
>     >
>     > 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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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 <mailto:jaosorior at gmail.com>
> 




More information about the OpenStack-dev mailing list