[openstack-dev] [nova] quota_fixed_ips cfg parameter

Michael Still mikal at stillhq.com
Thu Mar 21 19:48:54 UTC 2013


On Fri, Mar 22, 2013 at 4:30 AM, Lloyd Dewolf <lloydostack at gmail.com> wrote:
> I'm trying to understand why per instances fixed ip limit was rejected as a
> better approach. (1) this is a feature specific solution -- only impacts if
> multinic or similar extensions are in play. (2) The math is easy. Default
> set it to 4 (or 2 or 1) multiple by number of instances multiple by projects
> is the total number of fixed IPs that can be exhausted, and only instances x
> fixed ip limit for any particular bad actor.
>
> Per instances fixed ip seems like the better general solution possibly with
> the current implementation being a good override for public clouds.

First off, thanks for commenting on this. I personally would have
liked to have more of a design discussion around all of this at the
time, but the nature of embargoed security fixes makes that hard.

So, why is the default ten? The short answer is that the default
instance quota is ten, and I felt that the most likely use case was
one fixed ip for instance, and therefore used the same number. That
default is trivial to change if we decide we should.

Why not a per instance quota? Well, the underlying quota engines in
essex, folsom, and grizzly (yes, they're all different) don't have any
per-instance quotas so that's likely a much bigger code change. I
would expect to see push back from the essex and folsom maintainers if
I wanted to push more than the bare minimum code into those trees. We
could have done something like that in grizzly, but then the
transition from folsom to grizzly would be confusing.

On the other hand, I've had to help more people in the last week than
I expected with setting this quota. It seems people haven't noticed it
being added, and we're not very good at making it obvious that an
instance is in error state because of a quota problem (you need to
look at logs, not "nova list") output. There's definitely room from
improvement there.

Michael



More information about the OpenStack-dev mailing list