Associating an already-associated floating IP with another instance
results in the floating IP being first disassociated from the original
instance and then associated with the second instance.
However when this transfer of the floating IP to the second instance
occurs, the network info held in the database instance info cache was
previously only updated for the second instance (via the
@nova.network.api.refresh_cache decorator).
As a result, the floating IP was initially reported as being associated
with *both* instances. This misreporting is temporary - eventually the
periodic heal_instance_info_cache task will roll around and purge the
inaccurante network info for the original instance. However depending
on the frequency configured for this task and the size of the instance
population, it could take a while for the refresh to occur.
This issue is addressed by immediately purging the obsolute network info
when the reassignment occurs.
Reviewed: https:/ /review. openstack. org/10532 github. com/openstack/ nova/commit/ 6a5f095b0a9a73c 57469b4e5f10694 d1b738527f
Committed: http://
Submitter: Jenkins
Branch: master
commit 6a5f095b0a9a73c 57469b4e5f10694 d1b738527f
Author: Eoghan Glynn <email address hidden>
Date: Fri Jul 27 20:34:05 2012 +0100
Avoid associating floating IP with two instances.
Addresses LP 1029911.
Associating an already-associated floating IP with another instance
results in the floating IP being first disassociated from the original
instance and then associated with the second instance.
However when this transfer of the floating IP to the second instance network. api.refresh_ cache decorator).
occurs, the network info held in the database instance info cache was
previously only updated for the second instance (via the
@nova.
As a result, the floating IP was initially reported as being associated info_cache task will roll around and purge the
with *both* instances. This misreporting is temporary - eventually the
periodic heal_instance_
inaccurante network info for the original instance. However depending
on the frequency configured for this task and the size of the instance
population, it could take a while for the refresh to occur.
This issue is addressed by immediately purging the obsolute network info
when the reassignment occurs.
Change-Id: Ibfb04997ff4a98 3d144d81350857c b07475aff54