max_fixed_ips_per_port appears to be unnecessary

Fix proposed to branch: master
Review: https://review.openstack.org/230696

You're grounded.

...and you know why.

Ok, messing with ya.

Reviewed: https://review.openstack.org/230696
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=37277cf4168260d5fa97f20e0b64a2efe2d989ad
Submitter: Jenkins
Branch: master

commit 37277cf4168260d5fa97f20e0b64a2efe2d989ad
Author: Kevin Benton <email address hidden>
Date: Wed Sep 30 04:20:02 2015 -0700

    Deprecate max_fixed_ips_per_port

    This option does not have a clear use case since we prevent
    users from setting their own IP addresses on shared networks.

    DocImpact
    Change-Id: I211e87790c955ba5c3904ac27b177acb2847539d
    Closes-Bug: #1502356

This issue was fixed in the openstack/neutron 8.0.0.0b1 development milestone.

For a pubic cloud where we want to prevent/limit the usage of excessive IPs on a single port, this option is extremely useful.

It allows us to avoid having a customer who has 200 IPs on a single instance, for a few minutes, all done to send spam. While port or fixed IP quotas can be useful, sometimes we want to limit it per specific instance and this is the perfect case for it.

Can we look into adding this again? On our public cloud, customers can plug directly into the public network.

@Mohammed, do you allow the customers to specify their own IP addresses on the public network?

@Mohammed, note that it has only been deprecated. It would be good to collect feedback like yours to develop a better quota system for these types of use cases.

Hello,

We do allow customers to add more IPs to their ports (as well as using the
add-fixed-up feature in Nova).

They indeed can get new IPs on the public network (and potentially choose
them as per the API)

Thanks
M

On Thursday, 10 March 2016, Kevin Benton <email address hidden> wrote:

> @Mohammed, do you allow the customers to specify their own IP addresses
> on the public network?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1502356
>
> Title:
> max_fixed_ips_per_port appears to be unnecessary
>
> Status in neutron:
> Fix Released
>
> Bug description:
> The option max_fixed_ips_per_port was introduced under the idea of
> preventing users from eating up IP addresses on shared networks that
> they don't own. However, we already prevent users from updating the
> fixed_ips of their port on networks that they don't own.[1]
>
> Unless there is a use case for this option that I am missing, we
> should just deprecate this option. Please provide use cases if you
> think otherwise.
>
>
> 1.
> https://github.com/openstack/neutron/blob/82866276b0cf7a10cbb9f5e92a12680b096a3770/etc/policy.json#L78
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/1502356/+subscriptions
>

--
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. <email address hidden>
W. http://vexxhost.com

@Mohammed: did you change the default policy that prevents regular tenants from allocating fixed ips directly on networks they do not own? Can you elaborate on your use case, because providing a static global config to limit IP allocation when explicitly asking individual IPs ends up breaking DHCP allocation in circumstances where a network has more subnets than the defined limit.

Related fix proposed to branch: master
Review: https://review.openstack.org/291471

Reviewed: https://review.openstack.org/291471
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fc661571765054ff09e41aa6c7fc32f80fd0a98d
Submitter: Jenkins
Branch: master

commit fc661571765054ff09e41aa6c7fc32f80fd0a98d
Author: Kevin Benton <email address hidden>
Date: Thu Mar 10 14:04:12 2016 -0800

    Add reno for deprecation of max_fixed_ips_per_port

    This patch adds the release note to increase operator visibility.

    The release notes system was not present when this option was
    deprecated at the start of the Mitaka cycle so no release note
    was created.

    Change-Id: Ice97f8790c0b5f8dbed9e89cf1cd74536cccdd8c
    Related-Bug: #1502356

This is actually used by a number of different plugins. The plugins have a DHCP backend that have a 1:1 mapping between a MAC and IP.
So removing this would be problematic

You can always hardcode the limitation and make your plugin barf at the request. Let's discuss more what's needed rather than going ahead with a revert.

Related fix proposed to branch: master
Review: https://review.openstack.org/364088

Change abandoned by garyk (<email address hidden>) on branch: master
Review: https://review.openstack.org/363602
Reason: https://review.openstack.org/364088

Maybe this will address your concerns about removing this configuration variable.

Then we can implement the business logic however we want, check subnets if they have DHCP enabled etc.

I Hope that you are open to this if not we need to move this to N different methods all over the code

Change abandoned by garyk (<email address hidden>) on branch: master
Review: https://review.openstack.org/364088
Reason: Addressed in plugin. Can blow this variable away

Reviewed: https://review.openstack.org/490070
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=49a0555129588b5c5d33eccb11231fc60689fcdd
Submitter: Jenkins
Branch: master

commit 49a0555129588b5c5d33eccb11231fc60689fcdd
Author: Gary Kotton <email address hidden>
Date: Tue Aug 1 14:34:50 2017 +0300

    Remove configuration options max_fixed_ips_per_port

    This was marked as deprecated in Newton.

    Related-bug: #1502356

    Change-Id: Iafaa340a9291e1ee84e776ddfffc5f870f7e67e2

this parameter is still available in newton & customer wants to use it..Do any one have an idea of max. configurable value of this parameter?