Neutron fip association doesn't work with service chains
Bug #1588099 reported by
Subrahmanyam Ongole
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Group Based Policy |
Confirmed
|
High
|
Subrahmanyam Ongole | ||
Bug Description
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.
Revision history for this message
| Subrahmanyam Ongole (osms69) wrote | #1 |
| Changed in group-based-policy: | |
| milestone: | none → next |
| assignee: | nobody → Subrahmanyam Ongole (osms69) |
| importance: | Undecided → High |
| status: | New → Confirmed |
To post a comment you must log in.
Some analysis..
https:/
we pass a router_id using which we make a call to create_floatingip:
https:/
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:/
makes a call to:
https:/
which in turn makes a call to:
https:/
_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:/
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?).