Problem:
On cfg channel change sequence of event was to select a new cfg peer if
available(sequence number incremented say S1) and then notify all config to new
cfg server and then again increment sequence number(S2).
This used to result in all the notified config to be present with S1. Now when
they are put for delete current sequence number S2 does not match with S1.
This results in inconsistency and VM fails.
Second increment of sequence number is present to mark all config as stale if no
new cfg server is selected in non headless mode.
Solution:
If active peer is selected then do not increment sequence number again(i.e. no
S2).
Closes-bug: #1593716
(cherry picked from commit 69cad55c2bd9127060011a1c37cd0ddbb5f4a865)
Reviewed: https:/ /review. opencontrail. org/33789 github. com/Juniper/ contrail- controller/ commit/ 52a0fdaae74b2c3 8b58dc443129fe9 3a336081a7
Committed: http://
Submitter: Zuul (<email address hidden>)
Branch: R2.21.x
commit 52a0fdaae74b2c3 8b58dc443129fe9 3a336081a7
Author: Manish <email address hidden>
Date: Wed Aug 17 14:39:40 2016 +0530
VM cleanup fails sometimes.
Problem:
On cfg channel change sequence of event was to select a new cfg peer if
available(sequence number incremented say S1) and then notify all config to new
cfg server and then again increment sequence number(S2).
This used to result in all the notified config to be present with S1. Now when
they are put for delete current sequence number S2 does not match with S1.
This results in inconsistency and VM fails.
Second increment of sequence number is present to mark all config as stale if no
new cfg server is selected in non headless mode.
Solution:
If active peer is selected then do not increment sequence number again(i.e. no
S2).
Closes-bug: #1593716 060011a1c37cd0d dbb5f4a865)
(cherry picked from commit 69cad55c2bd9127
Change-Id: I7d0685df007599 c614745b564b883 33efcfbe0f6