On 05/29/2013 08:48 AM, Doug Hellmann wrote: > > > > On Wed, May 29, 2013 at 6:12 AM, Thierry Carrez <thie...@openstack.org > <mailto:thie...@openstack.org>> wrote: > > Robert Collins wrote: > > On the other hand, we're finding a large chunk of the work we're doing > > is changing defaults. > > > > If we were changing them down from 'this works for prod clouds' to > > 'this works for a test cloud' - that would be fine. But we're changing > > them *up* : larger sqlalchemy pools, larger quotas for 'admin', larger > > quotas for end users. > > > > Another large chunk of the bring up is determining private network > > details w/in Quantum - something that isn't (typically) exposed to > > either the real world *or* other machines w/in the datacentre. > > > > So I find myself asking two questions: > > > > a) why aren't the defaults suitable for production? Where they are not > > suitable, it's just friction waiting to trip new deployers up. > > > > b) perhaps we can document - or even automate - some defaults for > > things like Quantum topology, which will work ok everywhere, and which > > we can tell folk who are just getting going 'follow this, it will work > > well enough for you to get experience with the rest of the system'.. > > Default values always target a specific use case, as for some parameters > there is just no default value that works for "most cases". > > The trick is to define a target use case for your defaults, and not have > half the default values care for a all-in-one while the others care for > a thousand nodes deployment. You'll always create friction for some > categories of users, but at least it should be a consistent friction :) > > Alternatively you can ship multiple sets of defaults (I remember MySQL > doing this for some time) if it's difficult to get documentation to > cover the various use cases.
These went stale very quickly... > 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. I'm going to suggest a "moderate" size default suggestion. What if our defaults are sensible for a single rack of gear? It seems to be a common enough unit of measure - and having a rack-sized set of defaults on a couple of machines probably won't kill much. OTOH - if you're doing a data center, there is NO WAY you're going to not configure something. > -- > Thierry Carrez (ttx) > Release Manager, OpenStack > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev