On 2014-02-13 09:01, Clint Byrum wrote:
Excerpts from David Kranz's message of 2014-02-13 06:38:52 -0800:
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.
Just taking a look at that issue, Keystone's PKI and revocation are
causing all kinds of issues with performance that are being tackled
with
a bit of a redesign. I doubt we can find a cache timeout setting that
will work generically for everyone, but if we make detecting revocation
scale, we won't have to.
The default probably is too low, but raising it too high will cause
concern with those who want revoked tokens to take effect immediately
and are willing to scale the backend to get that result.
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.
I don't know that we have been clear enough about this, but nobody has
ever challenged the assertion we've been making for a while in TripleO
which is that OpenStack _must_ have production defaults. We don't make
OpenStack for devstack.
Especially since devstack has config overrides in place to make sure
everything is set up the way it needs. There's absolutely no reason to
set a default because devstack needs it - just have devstack set it when
it runs.
Of course, what qualifies as production-ready for my single-node
OpenStack installation may not be appropriate for a 10000 node
installation. Basically what you talked about above with Keystone.
Some of those defaults might not be as easy to set, but it should be a
more manageable subset of options that have that problem.
In TripleO, we consider it a bug when we can't run with a default value
that isn't directly related to whatever makes that cloud unique. So
the virt driver: meh, that's a choice, but leaving file injection on is
really not appropriate for 99% of users in production. Also you'll see
quite a few commits from me in the keystone SQL token driver trying to
speed it up because the old default token backend was KVS (in-memory),
which was fast, but REALLY not useful in production. We found these
things by running defaults and noticing in a long running cloud where
the performance problems are, and we intend to keep doing that.
So perhaps we should encode this assertion in
https://wiki.openstack.org/wiki/ReviewChecklist
+1
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?
TripleO is the official "deployment" program. We are taking the
approach
described above. We're standing up several smallish (<50 nodes) clouds
with the intention of testing the defaults on real hardware in the gate
of OpenStack eventually.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
