<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-13 23:19 GMT+08:00 Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, 2014-02-13 at 09:38 -0500, David Kranz wrote:<br>
> I was recently bitten by a case where some defaults in keystone.conf<br>
> were not appropriate for real deployment, and our puppet modules were<br>
> not providing better values<br>
> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1064061" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1064061</a>. Since there are<br>
> hundreds (thousands?) of options across all the services. I am wondering<br>
> whether there are other similar issues lurking and if we have done what<br>
> we can to flush them out.<br>
><br>
> Defaults in conf files seem to be one of the following:<br>
><br>
> - Generic, appropriate for most situations<br>
> - Appropriate for devstack<br>
> - Appropriate for small, distro-based deployment<br>
> - Approprate for large deployment<br>
><br>
> Upstream, I don't think there is a shared view of how defaults should be<br>
> chosen.<br>
><br>
> Keeping bad defaults can have a huge impact on performance and when a<br>
> system falls over but the problems may not be visible until some time<br>
> after a system gets into real use. Have the folks creating our puppet<br>
> modules and install recommendations taken a close look at all the<br>
> options and determined<br>
> that the defaults are appropriate for deploying RHEL OSP in the<br>
> configurations we are recommending?<br>
<br>
</div>This is a very common problem in the configuration management space,<br>
frankly. One good example is the upstream mysql Chef cookbook keeping<br>
ludicrously low InnoDB buffer pool, log and data file sizes. The<br>
defaults from MySQL -- which were chosen, frankly, in the 1990s, are<br>
useful for nothing more than a test environment, but unfortunately they<br>
propogate to far too many deployments with folks unaware of the serious<br>
side-effects on performance and scalability until it's too late [1].<br>
<br>
I think it's an excellent idea to do a review of the values in all of<br>
the configuration files and do the following:<br>
<br>
* Identify settings that simply aren't appropriate for anything and make<br>
the change to a better default.<br>
<br>
* Identify settings that need to scale with the size of the underlying<br>
VM or host capabilities, and provide patches to the configuration file<br>
comments that clearly indicate <div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small;display:inline"></div>a recommended scaling factor. Remember<br>
that folks writing Puppet modules, Ansible scripts, Salt SLS files, and<br>
Chef cookbooks look first to the configuration files to get an idea of<br>
how to set the values.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small">Good idea! +1 for providing a recommended scaling factor for the related settings</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
-jay<br>
<br>
[1] The reason I say it's "too late" is because for some configuration<br>
value -- notably innodb_log_file_size and innodb_data_file_size -- it is<br>
not possible to change the configuration values after data has been<br>
written to disk. You need to literally dump the contents of the DBs and<br>
reload the database after removing the files and restarting the DBs<br>
after changing the configuration options in my.cnf. See this bug for<br>
details on this pain in the behind:<br>
<br>
<a href="https://tickets.opscode.com/browse/COOK-2100" target="_blank">https://tickets.opscode.com/browse/COOK-2100</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><b><font color="#000000" style="background-color:rgb(243,243,243)" face="courier new, monospace">---------------------------------------</font></b></div>
<div><font color="#0000ff" face="comic sans ms, sans-serif"><b>Lingxian Kong</b></font></div><div><font color="#ff00ff" face="comic sans ms, sans-serif">Huawei Technologies Co.,LTD.</font></div><div><font color="#ff00ff" face="comic sans ms, sans-serif">IT Product Line CloudOS PDU</font></div>
<div><font color="#ff00ff" face="comic sans ms, sans-serif">China, Xi'an</font></div><div><font color="#ff00ff" face="comic sans ms, sans-serif">Mobile: +86-18602962792</font></div><div><font color="#ff00ff" face="comic sans ms, sans-serif">Email: <a href="mailto:konglingxian@huawei.com" target="_blank">konglingxian@huawei.com</a>; <a href="mailto:anlin.kong@gmail.com" target="_blank">anlin.kong@gmail.com</a></font></div>
</div>
</div></div>