<div dir="ltr"><div><div><div>>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></div>If by our puppet modules you mean the ones in stackforge, in the vast majority of cases they follow the defaults provided.  I check that this is the case during review, and the only exceptions should be stuff like the db and mq locations that have to change for almost every install.<br>
</div><div><br> - Michael<br></div></div><div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 15, 2014 at 10:15 AM, Dirk Müller <span dir="ltr"><<a href="mailto:dirk@dmllr.de" target="_blank">dirk@dmllr.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">>> 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>.<br>
<br>
</div>I'd agree that raising the caching timeout is a not a good "production<br>
default" choice. I'd also argue that the underlying issue is fixed<br>
with <a href="https://review.openstack.org/#/c/69884/" target="_blank">https://review.openstack.org/#/c/69884/</a><br>
<br>
In our testing this patch has speed up the revocation retrieval by factor 120.<br>
<div class=""><br>
> The default probably is too low, but raising it too high will cause<br>
> concern with those who want revoked tokens to take effect immediately<br>
> and are willing to scale the backend to get that result.<br>
<br>
</div>I agree, and changing defaults has a cost as well: Every deployment<br>
solution out there has to detect the value change, update their config<br>
templates and potentially also migrate the setting from the old to the<br>
new default for existing deployments. Being in that situation, it has<br>
happened that we were "surprised" by default changes that had<br>
undesireable side effects, just because we chose to overwrite a<br>
different default elsewhere.<br>
<br>
I'm totally on board with having "production ready" defaults, but that<br>
also includes that they seldomly change and change only for a very<br>
good, possibly documented reason.<br>
<br>
<br>
Greetings,<br>
Dirk<br>
<div class="HOEnZb"><div class="h5"><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></div>