Open Stack

On Mon, Jun 24, 2013 at 3:46 PM, Monty Taylor <mordred at inaugust.com> wrote:

>
>
> 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.
>


For a concrete example, rate limiting.


https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/limits.py#L225

Here are the current values:

DEFAULT_LIMITS = [

    Limit("POST", "*", ".*", 10, PER_MINUTE),
    Limit("POST", "*/servers", "^/servers", 50, PER_DAY),
    Limit("PUT", "*", ".*", 10, PER_MINUTE),
    Limit("GET", "*changes-since*", ".*changes-since.*", 3, PER_MINUTE),
    Limit("DELETE", "*", ".*", 100, PER_MINUTE),
    Limit("GET", "*/os-fping", "^/os-fping", 12, PER_HOUR),
]

What do people use in production, or do you use it at all?

Rate limiting to 10 POSTS per minute and 50 servers per day seems
*way* to low for any sort of deployment - production or otherwise.



>
>
> >     --
> >     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
> >
>
> _______________________________________________
> 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/20130624/18c3b76a/attachment.html>