On 11/23/2015 01:20 AM, Juan Antonio Osorio wrote: > > > On Sat, Nov 21, 2015 at 2:05 AM, Ben Nemec <openst...@nemebean.com > <mailto:openst...@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-requ...@lists.openstack.org?subject:unsubscribe > <http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Juan Antonio Osorio R. > e-mail: jaosor...@gmail.com <mailto:jaosor...@gmail.com> > __________________________________________________________________________ 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
