[LISPMAP-135] Clustering: operational data is not showing up in the in-memory map-cache on the replicas Created: 25/Aug/16  Updated: 08/Sep/16  Resolved: 08/Sep/16

Status: Resolved
Project: lispflowmapping
Component/s: Service
Affects Version/s: Boron
Fix Version/s: None

Type: Bug
Reporter: Lori Jakab Assignee: Vina Ermagan
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 6536
Priority: Highest

 Description   

Whatever is written in the operational MD-SAL data-store is replicated in the cluster, but our ClusteredDataTreeChangeListener is only watching the configration data-store, so we don't get notifications for mappings added from the southbound. Southbound mappings don't follow the same pattern for adding to the map-cache as the other operations.

 Comments   
Comment by Vina Ermagan [ 02/Sep/16 ]

This seems to be a blocker bug as further testing shows after failure operational is still inconsistent. DataListener should propagate SB originated changes if the node is not Master.

Comment by A H [ 02/Sep/16 ]

Is there an ETA for this bug and someone assigned to fix?

Comment by Vina Ermagan [ 02/Sep/16 ]

Vina and Lori are working on this. Targeting Friday for fix. But for fix and post fix testing eta may likely be as long as next Tue.

Comment by Lori Jakab [ 05/Sep/16 ]

Proposed fix: https://git.opendaylight.org/gerrit/#/c/45151/

This may not be the proper long term solution, but I think we can release with this, since it fixes the issue.

Comment by A H [ 05/Sep/16 ]

Can we cherry pick to stable/boron?

Comment by A H [ 05/Sep/16 ]

To better assess the impact of this bug and fix, could someone from your team please help us identify the following:
Severity: Could you elaborate on the severity of this bug? Is this a BLOCKER such that we cannot release Boron without it? Is there a workaround such that we can write a release note and fix in future Boron SR1?
Testing: Could you also elaborate on the testing of this patch? How extensively has this patch been tested? Is it covered by any unit tests or system tests?
Impact: Does this fix impact any dependent projects?

Comment by Lori Jakab [ 05/Sep/16 ]

(In reply to A H from comment #6)
> To better assess the impact of this bug and fix, could someone from your
> team please help us identify the following:
> Severity: Could you elaborate on the severity of this bug? Is this a
> BLOCKER such that we cannot release Boron without it? Is there a workaround
> such that we can write a release note and fix in future Boron SR1?

I'll defer to Vina, our PTL on this question.

> Testing: Could you also elaborate on the testing of this patch? How
> extensively has this patch been tested? Is it covered by any unit tests or
> system tests?

Since this is clustering related and we don't yet have CSIT for clustering, there is no automated testing. Unit/integration tests can't cover clustering scenarios, AFAIK. The bug was discovered, and the patch was tested manually.

> Impact: Does this fix impact any dependent projects?

No.

Comment by Vina Ermagan [ 06/Sep/16 ]

This fix is now merged and cherrypicked to stable/boron: https://git.opendaylight.org/gerrit/#/c/45188/

Comment by A H [ 08/Sep/16 ]

Has this bug been verified as fixed in the latest Boron RC 3.1 Build?

Comment by Vina Ermagan [ 08/Sep/16 ]

RC 3.2 has been tested and verified as fixed for this bug.

Generated at Wed Feb 07 20:06:35 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.