2014-02-13 23:19 GMT+08:00 Jay Pipes <[email protected]>: > 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. >
Good idea! +1 for providing a recommended scaling factor for the related settings > > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- *---------------------------------------* *Lingxian Kong* Huawei Technologies Co.,LTD. IT Product Line CloudOS PDU China, Xi'an Mobile: +86-18602962792 Email: [email protected]; [email protected]
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
