<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 29, 2013 at 6:12 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Robert Collins wrote:<br>
> On the other hand, we're finding a large chunk of the work we're doing<br>
> is changing defaults.<br>
><br>
> If we were changing them down from 'this works for prod clouds' to<br>
> 'this works for a test cloud' - that would be fine. But we're changing<br>
> them *up* : larger sqlalchemy pools, larger quotas for 'admin', larger<br>
> quotas for end users.<br>
><br>
> Another large chunk of the bring up is determining private network<br>
> details w/in Quantum - something that isn't (typically) exposed to<br>
> either the real world *or* other machines w/in the datacentre.<br>
><br>
> So I find myself asking two questions:<br>
><br>
> a) why aren't the defaults suitable for production? Where they are not<br>
> suitable, it's just friction waiting to trip new deployers up.<br>
><br>
> b) perhaps we can document - or even automate - some defaults for<br>
> things like Quantum topology, which will work ok everywhere, and which<br>
> we can tell folk who are just getting going 'follow this, it will work<br>
> well enough for you to get experience with the rest of the system'.<br>
<br>
</div>Default values always target a specific use case, as for some parameters<br>
there is just no default value that works for "most cases".<br>
<br>
The trick is to define a target use case for your defaults, and not have<br>
half the default values care for a all-in-one while the others care for<br>
a thousand nodes deployment. You'll always create friction for some<br>
categories of users, but at least it should be a consistent friction :)<br>
<br>
Alternatively you can ship multiple sets of defaults (I remember MySQL<br>
doing this for some time) if it's difficult to get documentation to<br>
cover the various use cases.<br></blockquote><div><br></div><div style>It's easy for developers to override the defaults to work for all-in-one deployments via devstack. We should try to make the baked-in defaults more useful for non-development use cases. Perhaps the defaults should work for a "moderate" size with a few compute nodes (someone should suggest a specific number), which would make them useful for proof-of-concept setups. We can also ship separate example files for "large" deployments, as you suggest.</div>
<div style><br></div><div style>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
Release Manager, OpenStack<br>
</font></span><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></div>