[openstack-dev] [nova] quota_fixed_ips cfg parameter

Lloyd Dewolf lloydostack at gmail.com
Fri Mar 29 17:54:49 UTC 2013


On Thu, Mar 21, 2013 at 12:48 PM, Michael Still <mikal at stillhq.com> wrote:

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


Thanks for the detailed response Michael and congratulations in the
election! -- well deserved.

The engine not supporting per instance quotas is a perfect explanation.

I noted "Fixed IPs quota can break upgrades" resolution is to default to
-1. I'm happy for this as I see it as the pragmatic solution, with the risk
only introduced currently under extended functionality with multinic or
similar extensions.
https://bugs.launchpad.net/nova/+bug/1161190

Thanks for you Michael, Vish, Sam et all for your work on this!

Best,
Lloyd
--
@lloyddewolf
http://www.pistoncloud.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130329/ef701745/attachment.html>


More information about the OpenStack-dev mailing list