© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
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?).