commit 557681be3dfc3582c93938c13488089c8da6ac5d
Author: Nischal Sheth <email address hidden>
Date: Sat Feb 25 16:04:00 2017 -0800
Fix race condition in BGPaaS peering creation - take 2
If the internal ifmap configuration object for the routing-instance
for the bgp-routers that comprise a bgp-peering does not exist when
processing the bgp-peering, the ifmap config manager does create the
internal ifmap configuration object for the bgp-peering.
This causes the control node to not create the internal ifmap config
object for some bgp-peerings when the control node gets restarted in
a scaled bgpaas configuration. This happens for bgp-peerings which
get processed before the corresponding routing-instance has been
processed.
The previous fix did not cover the case where the notification for a
routing-instance has not been processed when the notification for the
instance-bgp-router link is processed.
Fix this by modifying dependency tracker policy to re-evaluate all of
the bgp-routers for a routing-instance when processing a notification
for the routing-instance itself. This in turn causes a re-evaluation
of all the bgp-peerings for those bgp-routers.
Reviewed: https:/ /review. opencontrail. org/29129 github. org/Juniper/ contrail- controller/ commit/ 557681be3dfc358 2c93938c1348808 9c8da6ac5d
Committed: http://
Submitter: Zuul (<email address hidden>)
Branch: R3.0
commit 557681be3dfc358 2c93938c1348808 9c8da6ac5d
Author: Nischal Sheth <email address hidden>
Date: Sat Feb 25 16:04:00 2017 -0800
Fix race condition in BGPaaS peering creation - take 2
If the internal ifmap configuration object for the routing-instance
for the bgp-routers that comprise a bgp-peering does not exist when
processing the bgp-peering, the ifmap config manager does create the
internal ifmap configuration object for the bgp-peering.
This causes the control node to not create the internal ifmap config
object for some bgp-peerings when the control node gets restarted in
a scaled bgpaas configuration. This happens for bgp-peerings which
get processed before the corresponding routing-instance has been
processed.
The previous fix did not cover the case where the notification for a
routing-instance has not been processed when the notification for the
instance-bgp-router link is processed.
Fix this by modifying dependency tracker policy to re-evaluate all of
the bgp-routers for a routing-instance when processing a notification
for the routing-instance itself. This in turn causes a re-evaluation
of all the bgp-peerings for those bgp-routers.
Change-Id: Idc4425c87037aa c1eb96f23394bfa e536c17546c
Closes-Bug: 1662678