Open Stack

On Wed, May 29, 2013 at 6:12 AM, Thierry Carrez <thierry at 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.
>

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.

Doug


>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130529/ec3536ab/attachment.html>