<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 24, 2013 at 6:46 PM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</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"><br>
<br>
On 05/29/2013 08:48 AM, Doug Hellmann wrote:<br>
><br>
><br>
><br>
> On Wed, May 29, 2013 at 6:12 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a><br>
</div><div class="im">> <mailto:<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>>> wrote:<br>
><br>
>     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>
</div>>     > well enough for you to get experience with the rest of the system'..<br>
<div class="im">><br>
>     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>
<br>
</div>These went stale very quickly...<br>
<div class="im"><br>
> It's easy for developers to override the defaults to work for all-in-one<br>
> deployments via devstack. We should try to make the baked-in defaults<br>
> more useful for non-development use cases. Perhaps the defaults should<br>
> work for a "moderate" size with a few compute nodes (someone should<br>
> suggest a specific number), which would make them useful for<br>
> proof-of-concept setups. We can also ship separate example files for<br>
> "large" deployments, as you suggest.<br>
<br>
</div>I'm going to suggest a "moderate" size default suggestion.<br>
<br>
What if our defaults are sensible for a single rack of gear? It seems to<br>
be a common enough unit of measure - and having a rack-sized set of<br>
defaults on a couple of machines probably won't kill much. OTOH - if<br>
you're doing a data center, there is NO WAY you're going to not<br>
configure something.<br></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
>     --<br>
>     Thierry Carrez (ttx)<br>
>     Release Manager, OpenStack<br>
><br>
>     _______________________________________________<br>
>     OpenStack-dev mailing list<br>
>     <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</div>>     <mailto:<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 class="HOEnZb"><div class="h5">><br>
><br>
><br>
><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>
><br>
<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>