Details
-
Task
-
Resolution: Fixed
-
Blocker
-
2.5.0
-
None
-
Security Level: Public
-
None
-
all platforms
-
TP Sprint Jan 15-28 2015
Description
Scenario
-------------
Let's assume uni-xdcr for:
cluster A -----> cluster E
cluster B -----> cluster E
cluster C -----> cluster E
Now we add cluster D -->cluster E. While doing so, the inbound xdcr for E info is not available on GUI(not sure if we have REST API call). If the user regenerates the cluster certificate for E, all replications from A,B,C will fail/stop with the not-so-useful replication errors :[Vb Rep] Error replicating vbucket <nnn>. Please see logs for details.
In this case,
1. cluster admins of A,B,C will have no clue why replication suddenly stopped - no indication even in xdcr log.
2. user who regenerated E's certificate will not know which other cluster(s) to update(with E's new certificate).
The above is an exaggerated version of my test scenario, a simple A->B. B's certificate changes, replication simply stops as detailed above. Attaching screenshots.
Expectation
----------------
Although adding a meaningful error message would tell the admins of A,B,C that replication failed due to an external error, I'm more concerned about the case where the user regenerating E's certificate, would not even know which other clusters to update with it. What's the recommended solution?
Maybe add inbound xdcr info for a cluster on GUI/API/CLI as warning while trying to regenerate its certificate?
Attachments
Issue Links
- relates to
-
MB-9928 XDCR-SSL : uni-xdcr - if remote cluster's certificate changes, existing replication(s) simply stops + no clarity on how to trace the source clusters for certificate updation
- Closed