<div dir="ltr">David, <div><br></div><div>Good that you rise this topic. It is actually sad that you have to make a big investigation of OpenStack config params, before you are able to use OpenStack. I think that this work should be done mostly inside upstream.<br>
</div><div><br></div><div><br></div><div>So I have a couple of ideas how we can simplify investigation of how CONF values impact on performance at scale (without having tons of servers).</div><div><br></div><div>In closer future you will be able to use Rally [1] for it:</div>
<div>1) (WIP) Deploy multinode installation in click inside lxc containers [2] (you need only 200 MB of Ram for 1 compute node)</div><div>2) Use fake virtualization</div><div>3) Run rally benchmarks and get performance for different conf parameters</div>
<div>4) Analyze results and set as default best one. </div><div>5) (WIP) I am working as well on pure OpenStack cross service profiler [3], that will allows us to find slow parts of code, and analyze CONF args that are related to them. (not whole list of cong params)</div>
<div><br></div><div><br></div><div><br></div><div>[1] <a href="https://wiki.openstack.org/wiki/Rally">https://wiki.openstack.org/wiki/Rally</a></div><div>[2] <a href="https://review.openstack.org/#/c/57240/27/doc/samples/deployments/multihost.rst">https://review.openstack.org/#/c/57240/27/doc/samples/deployments/multihost.rst</a></div>
<div>[3] <a href="https://github.com/pboris/osprofiler">https://github.com/pboris/osprofiler</a></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 6:38 PM, David Kranz <span dir="ltr"><<a href="mailto:dkranz@redhat.com" target="_blank">dkranz@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1064061" target="_blank">https://bugzilla.redhat.com/<u></u>show_bug.cgi?id=1064061</a>. 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.<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 chosen.<br>
<br>
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<br>

that the defaults are appropriate for deploying RHEL OSP in the configurations we are recommending?<br>
<br>
 -David<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div>