Neutron fip association doesn't work with service chains

[Subrahmanyam Ongole]

When firewall service is launched, gw port is removed from router and attached to firewall service VM. After this point, floating IPs can't be associated to PTs in the provider PTG, as they are no longer directly reachable from router.

However, implicit fip association using network service policy (nsp) works.

[Subrahmanyam Ongole (osms69)]

Some analysis..

https://github.com/openstack/group-based-policy/blob/dab68def4ad157548aaee62056727a5617c49cd7/gbpservice/neutron/services/grouppolicy/drivers/resource_mapping.py#L355-L357

we pass a router_id using which we make a call to create_floatingip:

https://github.com/openstack/group-based-policy/blob/dab68def4ad157548aaee62056727a5617c49cd7/gbpservice/neutron/services/grouppolicy/drivers/resource_mapping.py#L375-L378

you use the explicit neutron workflow to update the floating IP association, its never going to come to us

----------------
Alternatives suggested
----------------

1. create neutron extension API for update which takes router_id

2. monkey patch update fip and somehow derive router_id

monkey-patching the update_floatingip of Neutron
so if you see this:
https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L1201
makes a call to:
https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L1173
which in turn makes a call to:
https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L1183
_update_fip_assoc

which we have monkey patches
*patched
in _update_fip_assoc we expect that the router_id is already set
so somehow, whatever is calling _update_fip_assoc needs to pass in that router_id

the earlier sequence is in the resource_mapping driver is doing this for the create case

We do the following from the resource_mapping driver to get the router_id:
https://github.com/openstack/group-based-policy/blob/dab68def4ad157548aaee62056727a5617c49cd7/gbpservice/neutron/services/grouppolicy/drivers/resource_mapping.py#L346-L357

One would need to do something similar from a update_floatingip monkey
patch, but the problem is you don’t have any GBP context inside that
Neutron method!

One way could be to see if a route exists between the internal port and the external network (can be done traversing the extra-route API). But it's not clear how that would work if the path breaks at some point (eg. An intermediate router is deleted... should we return a fault? Disallow router deletion?).