On Mon, Jun 24, 2013 at 6:46 PM, Monty Taylor <mord...@inaugust.com> wrote:
> > > 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. > +1 > > > > -- > > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev