Open Stack

On Sun, Nov 4, 2012 at 2:30 AM, Aniruddha Khadkikar
<askhadkikar at gmail.com> wrote:
> how the records are maintained. One can design the structure to
> include a 'version' column along with a boolean attribute for logical
> deletion of records. This would allow storing information across
> different versions. Puppet has its use, but the main point is that the
> metadata should lie within openstack and not solely outside in a
> configuration management tool (i.e. Puppet). With so many
> configuration parameters in quantum, nova, swift, cinder, we need an
> easy way to be able to query 'global' values and if required be able
> to specify 'local' values applicable to nodes also, if such a need
> arises. Areas where local values could be required could be location
> of log files, different tuning parameters depending on hardware
> configuration etc.

I question 'need' here: plain text files have a lot of value for local
software configuration: we need to avoid adding complexity for its own
sake: its *how* we got to 500 config options in the first place.

That said, I'm *very* much in favour of having a queryable config
store for high level policy - and we can let things evolve over time
to see what options make sense there and what don't. The sort of thing
I'm thinking of is feature flags [is everyone familiar with those
these days?], and also broad knobs like overcommit rate, where
restarting a bunch of services to activate changes is just a nuisance,
particularly when responding to an in-progress incident.

Another thing to note is that in keystone, and in the various quota
systems, we already have policy datastores which supersede many of the
500 options you reference - things from the early days have been made
customisable per tenant now; perhaps its a matter of identifying how
many options folk /actually/ use these days, and which are merely for
backwards compat [or could we delete them and ignore them if they are
still set on upgrades...]

-Rob