Open Stack

On Thu, 2014-02-13 at 09:38 -0500, David Kranz wrote:
> I was recently bitten by a case where some defaults in keystone.conf 
> were not appropriate for real deployment, and our puppet modules were 
> not providing better values 
> https://bugzilla.redhat.com/show_bug.cgi?id=1064061. Since there are 
> hundreds (thousands?) of options across all the services. I am wondering 
> whether there are other similar issues lurking and if we have done what 
> we can to flush them out.
> 
> Defaults in conf files seem to be one of the following:
> 
> - Generic, appropriate for most situations
> - Appropriate for devstack
> - Appropriate for small, distro-based deployment
> - Approprate for large deployment
> 
> Upstream, I don't think there is a shared view of how defaults should be 
> chosen.
> 
> Keeping bad defaults can have a huge impact on performance and when a 
> system falls over but the problems may not be visible until some time 
> after a system gets into real use. Have the folks creating our puppet 
> modules and install recommendations taken a close look at all the 
> options and determined
> that the defaults are appropriate for deploying RHEL OSP in the 
> configurations we are recommending?

This is a very common problem in the configuration management space,
frankly. One good example is the upstream mysql Chef cookbook keeping
ludicrously low InnoDB buffer pool, log and data file sizes. The
defaults from MySQL -- which were chosen, frankly, in the 1990s, are
useful for nothing more than a test environment, but unfortunately they
propogate to far too many deployments with folks unaware of the serious
side-effects on performance and scalability until it's too late [1].

I think it's an excellent idea to do a review of the values in all of
the configuration files and do the following:

* Identify settings that simply aren't appropriate for anything and make
the change to a better default.

* Identify settings that need to scale with the size of the underlying
VM or host capabilities, and provide patches to the configuration file
comments that clearly indicate a recommended scaling factor. Remember
that folks writing Puppet modules, Ansible scripts, Salt SLS files, and
Chef cookbooks look first to the configuration files to get an idea of
how to set the values.

Best,
-jay

[1] The reason I say it's "too late" is because for some configuration
value -- notably innodb_log_file_size and innodb_data_file_size -- it is
not possible to change the configuration values after data has been
written to disk. You need to literally dump the contents of the DBs and
reload the database after removing the files and restarting the DBs
after changing the configuration options in my.cnf. See this bug for
details on this pain in the behind:

https://tickets.opscode.com/browse/COOK-2100