Open Stack

David,

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.


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).

In closer future you will be able to use Rally [1] for it:
1) (WIP) Deploy multinode installation in click inside lxc containers [2]
(you need only 200 MB of Ram for 1 compute node)
2) Use fake virtualization
3) Run rally benchmarks and get performance for different conf parameters
4) Analyze results and set as default best one.
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)



[1] https://wiki.openstack.org/wiki/Rally
[2]
https://review.openstack.org/#/c/57240/27/doc/samples/deployments/multihost.rst
[3] https://github.com/pboris/osprofiler

Best regards,
Boris Pavlovic



On Thu, Feb 13, 2014 at 6:38 PM, David Kranz <dkranz at redhat.com> 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?
>
>  -David
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140213/584581c3/attachment.html>