<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 21, 2013 at 12:48 PM, Michael Still <span dir="ltr"><<a href="mailto:mikal@stillhq.com" target="_blank">mikal@stillhq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Fri, Mar 22, 2013 at 4:30 AM, Lloyd Dewolf <<a href="mailto:lloydostack@gmail.com">lloydostack@gmail.com</a>> wrote:<br>

> I'm trying to understand why per instances fixed ip limit was rejected as a<br>
> better approach. (1) this is a feature specific solution -- only impacts if<br>
> multinic or similar extensions are in play. (2) The math is easy. Default<br>
> set it to 4 (or 2 or 1) multiple by number of instances multiple by projects<br>
> is the total number of fixed IPs that can be exhausted, and only instances x<br>
> fixed ip limit for any particular bad actor.<br>
><br>
> Per instances fixed ip seems like the better general solution possibly with<br>
> the current implementation being a good override for public clouds.<br>
<br>
</div>First off, thanks for commenting on this. I personally would have<br>
liked to have more of a design discussion around all of this at the<br>
time, but the nature of embargoed security fixes makes that hard.<br>
<br>
So, why is the default ten? The short answer is that the default<br>
instance quota is ten, and I felt that the most likely use case was<br>
one fixed ip for instance, and therefore used the same number. That<br>
default is trivial to change if we decide we should.<br>
<br>
Why not a per instance quota? Well, the underlying quota engines in<br>
essex, folsom, and grizzly (yes, they're all different) don't have any<br>
per-instance quotas so that's likely a much bigger code change. I<br>
would expect to see push back from the essex and folsom maintainers if<br>
I wanted to push more than the bare minimum code into those trees. We<br>
could have done something like that in grizzly, but then the<br>
transition from folsom to grizzly would be confusing.<br>
<br>
On the other hand, I've had to help more people in the last week than<br>
I expected with setting this quota. It seems people haven't noticed it<br>
being added, and we're not very good at making it obvious that an<br>
instance is in error state because of a quota problem (you need to<br>
look at logs, not "nova list") output. There's definitely room from<br>
improvement there.</blockquote><div><br></div><div style>Thanks for the detailed response <span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Michael and congratulations in the election! -- well deserved.</span></div>
<div style><br></div><div style>The engine not supporting per instance quotas is a perfect explanation.</div><div style><br></div><div style>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 <span style="font-family:arial,sans-serif;font-size:12.727272033691406px">multinic or similar extensions.</span><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"> </span></div>
<div style><a href="https://bugs.launchpad.net/nova/+bug/1161190">https://bugs.launchpad.net/nova/+bug/1161190</a><br></div><div style><br></div><div style>Thanks for you Michael, Vish, Sam et all for your work on this!</div>
<div><br></div><div style>Best,</div><div style>Lloyd</div><div>--<br></div></div>@lloyddewolf<br><a href="http://www.pistoncloud.com/" target="_blank">http://www.pistoncloud.com/</a>
</div></div>