[openstack-dev] [TripleO] config options, defaults, oh my!

Robert Collins robertc at robertcollins.net
Mon Apr 7 20:00:30 UTC 2014


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? Also, some things
really should be higher order operations - like the neutron callback
to nova right - that should be either set to timeout in nova &
configured in neutron, *or* set in both sides appropriately, never
one-half or the other.

I think we need to sort out our approach here to be systematic quite
quickly to deal with these reviews.

Here's an attempt to do so - this could become a developers guide patch.

Config options in TripleO
==================

Non-API driven configuration falls into four categories:
A - fixed at buildtime (e.g. ld.so path)
B - cluster state derived
C - local machine derived
D - deployer choices

For A, it should be entirely done within the elements concerned.

For B, the heat template should accept parameters to choose the
desired config (e.g. the Neutron->Nova example able) but then express
the config in basic primitives in the instance metadata.

For C, elements should introspect the machine (e.g. memory size to
determine mysql memory footprint) inside os-refresh-config scripts;
longer term we should make this an input layer to os-collect-config.

For D, we need a sensible parameter in the heat template and probably
direct mapping down to instance metadata.

But we have a broader question - when should something be configurable at all?

In my mind we have these scenarios:
1) There is a single right answer
2) There are many right answers

An example of 1) would be any test-only option like failure injection
- the production value is always 'off'. For 2), hypervisor driver is a
great example - anything other than qemu is a valid production value
:)

But, it seems to me that these cases actually subdivide further -
1a) single right answer, and the default is the right answer
1b) single right answer and it is not the default
2a) many right answers, and the default is the most/nearly most common one
2b) many right answers, and the default is either not one of them or
is a corner case

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.

Thoughts?

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list