Open Stack

2014-02-13 23:19 GMT+08:00 Jay Pipes <jaypipes at gmail.com>:

> 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
> OpenStack-dev at lists.openstack.org
> 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: konglingxian at huawei.com; anlin.kong at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140214/6adccdcd/attachment.html>