HA routers are using keepalived and needs to have virtual_router_id
configured. As routers which belongs to same tenant are using same
ha network, those values have to be different for each router.
Before this patch this value was always taken as first available value
from available_vr_ids range.
In some (rare) cases, when more than one router is created in parallel
for same tenant it may happen that those routers would have same vr_id
choosen so keepalived would treat them as single application and only
one router would be ACTIVE on one of L3 agents.
This patch changes this behaviour that now random value from available
vr_ids will be chosen instead of taking first value always.
That should mittigate this rare race condition that it will be (almost)
not noticable for users.
However, proper fix should be probably done as some additional
constraint in database layer. But such solution wouldn't be possible to
backport to stable branches so I decided to propose this easy patch
first.
Change-Id: Idb0ed744e54976dca23593fb2d7317bf77442e65
Related-Bug: #1823314
(cherry picked from commit a8d0f557d504957aeb91f451105cca9eee2d6adb)
Reviewed: https:/ /review. openstack. org/651984 /git.openstack. org/cgit/ openstack/ neutron/ commit/ ?id=ee2ed681c49 5c4fc5086d76185 3731b7dc2fd34f
Committed: https:/
Submitter: Zuul
Branch: stable/rocky
commit ee2ed681c495c4f c5086d761853731 b7dc2fd34f
Author: Slawek Kaplonski <email address hidden>
Date: Wed Apr 10 12:49:49 2019 +0200
Choose random value for HA routes' vr_id
HA routers are using keepalived and needs to have virtual_router_id
configured. As routers which belongs to same tenant are using same
ha network, those values have to be different for each router.
Before this patch this value was always taken as first available value
from available_vr_ids range.
In some (rare) cases, when more than one router is created in parallel
for same tenant it may happen that those routers would have same vr_id
choosen so keepalived would treat them as single application and only
one router would be ACTIVE on one of L3 agents.
This patch changes this behaviour that now random value from available
vr_ids will be chosen instead of taking first value always.
That should mittigate this rare race condition that it will be (almost)
not noticable for users.
However, proper fix should be probably done as some additional
constraint in database layer. But such solution wouldn't be possible to
backport to stable branches so I decided to propose this easy patch
first.
Change-Id: Idb0ed744e54976 dca23593fb2d731 7bf77442e65 aeb91f451105cca 9eee2d6adb)
Related-Bug: #1823314
(cherry picked from commit a8d0f557d504957