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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev