Open Stack

On Tue, Apr 8, 2014 at 6:03 AM, Day, Phil <philip.day at hp.com> wrote:
>> -----Original Message-----
>> From: Robert Collins [mailto:robertc at robertcollins.net]
>> Sent: 07 April 2014 21:01
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [TripleO] config options, defaults, oh my!
>>
>> So one interesting thing from the influx of new reviews is lots of patches
>> exposing all the various plumbing bits of OpenStack. This is good in some
>> ways (yay, we can configure more stuff), but in some ways its kindof odd -
>> like - its not clear when https://review.openstack.org/#/c/83122/ is needed.
>>
>> I'm keen to expose things that are really needed, but i'm not sure that /all/
>> options are needed - what do folk think?
>
> I'm very wary of trying to make the decision in TripleO of what should and shouldn't be configurable in some other project.    For sure the number of config options in Nova is a problem, and one that's been discussed many times at summits.   However I think you could also make the case/assumption for any service that the debate about having a config option has already been held within that service as part of the review that merged that option in the code - re-running the debate about whether something should be configurable via TripleO feels like some sort of policing function on configurability above and beyond what the experts in that service have already considered, and that doesn't feel right to me.

This captures very well what I was thinking as well. I just don't
think it should be a question in TripleO if a config option should be
exposed or not.  I don't think any of the reviews we've had recently,
or are in the queue, folks have added just for the sake of exposing
more options. I assume it's because they actually wanted to tweak
those options.



>> So my proposal here - what I'd like to do as we add all these config options to
>> TripleO is to take the care to identify which of A/B/C/D they are and code
>> them appropriately, and if the option is one of 1b) or 2b) make sure there is a
>> bug in the relevant project about the fact that we're having to override a
>> default. If the option is really a case of 1a) I'm not sure we want it
>> configurable at all.
>>

> If the root cause of the problem is that every change to exploit a configurable feature of a deployed service needs an explicit matching change in TripleO, maybe that's a degree of tight coupling that needs to be addressed by having a more generic mechanism ?

Indeed, I think the implementation we have for configuration right now
that uses templates is a bit of a maintenance burden as Dan said.
Every time you want to expose a new configuration option, you need a
change to tripleo-image-elements to add it to the template, and
corresponding change to tripleo-heat-templates so that the option can
be set via Heat metadata.

This is similar I think (if not the same) as what Dan is proposing,
but I'd really like to see something along these lines instead:
- an implementation that used sample or generated config files for all
the OpenStack projects instead of templates
- a way for elements to specify their configuration for TripleO when
we can't use upstream defaults (json/yaml structure, etc). This
structure would get backed into the image for os-collect-config to
pick up and consume. Also a way for other elements to override others,
e.g., Nova element has some default configs, then the Ironic might
need to override some of those.
- enhance os-apply-config to have it support additional ways (iniset,
crudini, augeas, whatever) to modify config files instead of just
templatizing so that we can apply that baked-in config and additional
config from Heat when not using templates.

That solves the question of "what to expose" in the elements. Since
we're using sample/generated config files from the projects,
everything is exposed by default. When the upstream project adds a new
config option, it automatically gets exposed. Half of the ongoing
review burden is gone right there, with no developer guide needed
either.

Also part of the win...we'd have polished config files that look like
upstreams, except for the values of course :-). And, this also helps
get us going down the road of making the elements more discoverable in
terms of what can be configured and what the values are for TripleO,
something that I know Tuskar is very interested in having.

The question then becomes about what to do about exposing these
options in the Heat templates. We could keep the templates as we have
today, and just add parameters for the options that we know are useful
to us for the CD and CI use cases. We could then document how a user
would go about adding additional parameters to the templates that they
wanted exposed. Perhaps even give them a way to "merge" their custom
template snippets that add Parameters into those from
tripleo-heat-templates.

And, in fact, I think in most cases it *wouldn't* be a case of users
wanting to expose stuff so that they can have multiple values for it
in their environment. If that was true, I think we would have
identified those already and would have them exposed b/c it would
likely be useful to us as well.

Instead they likely need to have something exposed just to set it
differently, but that different value is the *same* across their
environment. In which case, they could just use a custom element that
provided some override json/yaml for os-collect-config during their
image builds.

-- 
-- James Slagle
--