Open Stack

On 05/29/2013 08:48 AM, Doug Hellmann wrote:
> 
> 
> 
> On Wed, May 29, 2013 at 6:12 AM, Thierry Carrez <thierry at openstack.org
> <mailto: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.

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 at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>