floating-ip association is allowed via router interface

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

While working on some interesting case for Manila integration with neutron, we found it very useful to have another range of floating ips to be associated with distinct network (in this case storage network) so it won't require to use external network addresses. For me this looks as a feature and not a bug :-)

@Irena, how did that end up working? Wouldn't the router have the IP address on the incorrect interface?

Kevin,

i guess it happens to work due to weak host model wrt ARP.

This is bug for me but I'm not sure that this bug is worth RC1. I guess that there are probably no use case that we process interface-add external NW into router.

@Kevin, I tried this with Midonet plugin (admit that didn't test yet with the reference implementation), and had to assure that midonet does not to assume gw port for the FIP but takes into account the subnet of the FIP. This places the NAT rule on the interface where FIP subnet (not the external net one) is connected.

I would like neutron to support this use case, as it helps the user (manila) to support multi-tenant environment by assigning VM a unique IP for the storage network. One of the options is to add specific API extension to allow additional router-interface for FIP allocation, but not sure if it's required.

While I consider it a bug if you look at it from the point of view that the validation was unintentionally removed in an unrelated patch, I also think that this is not really a bug in the sense that we already have at least one use case where this is useful, and we haven't come up with any reason why it's a problem. I would vote for keeping it as is unless the reference implementation does not handle this case.

Irena Berezovsky, Ryu Ishimoto: The feature was not intentionally added and we shouldn't merge it into project without discussion even if it's useful for someone . Can you start to discuss in Newton if you have the request for the feature?

Ryu,

even if it works perfectly (i doubt it), adding a feature this way defeats the purpose of extensions.
ie. allow a user to query features via api.

related rfe bug https://bugs.launchpad.net/neutron/+bug/1566191

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

commit 35aefdb54d58c786b26b10e1d0c550f7149e23fb
Author: YAMAMOTO Takashi <email address hidden>
Date: Mon Mar 14 20:38:28 2016 +0900

    Fix validation of floating-ip association

    A recently merged patch [1] allowed floating-ip via non-gateway port.
    This commit fixes the regression.

    This commit also provides an override point to allow plugins to choose
    the "broken" behaviour.

    [1] If054945eab058c7138aabbb22cda15890ccb502c

    Closes-Bug: #1556884
    Related-Bug: #1566191
    Change-Id: I5b824a209355bbb44d954e00ad47269ac0b903b5

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/325697

Reviewed: https://review.openstack.org/325697
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=cb36ef3828a8929ccdeec849ad8f4bba8f6bc137
Submitter: Jenkins
Branch: stable/mitaka

commit cb36ef3828a8929ccdeec849ad8f4bba8f6bc137
Author: YAMAMOTO Takashi <email address hidden>
Date: Mon Mar 14 20:38:28 2016 +0900

    Fix validation of floating-ip association

    A recently merged patch [1] allowed floating-ip via non-gateway port.
    This commit fixes the regression.

    This commit also provides an override point to allow plugins to choose
    the "broken" behaviour.

    [1] If054945eab058c7138aabbb22cda15890ccb502c

    Closes-Bug: #1556884
    Related-Bug: #1566191
    Change-Id: I5b824a209355bbb44d954e00ad47269ac0b903b5
    (cherry picked from commit 35aefdb54d58c786b26b10e1d0c550f7149e23fb)

This issue was fixed in the openstack/neutron 9.0.0.0b2 development milestone.

This issue was fixed in the openstack/neutron 8.2.0 release.