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).
Reviewed: https:/ /review. opencontrail. org/23366 github. org/Juniper/ contrail- controller/ commit/ 112aa3c8f475f29 0fdd5581c9c5927 e36f2d87e2
Committed: http://
Submitter: Zuul
Branch: master
commit 112aa3c8f475f29 0fdd5581c9c5927 e36f2d87e2
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).
Change-Id: I9e8bf4a6cfba36 ad45bac36182c73 ea2a835cdbf
Closes-bug: #1593716