Open Stack

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.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack