In cases where multiple operator instances are managing the same FDB cluster, like in the multi-dc setup, there can be a delay between a change in the coordinators and the operator instance updating the ConfigMap and all related resources. Especially in cases where only pods in a single dc are failing and the other operator instances are not receiving any events.
Code-Reviewer Section
The general pull request guidelines can be found here.
Please check each of the following things and check all boxes before accepting a PR.
[x] The PR has a description, explaining both the problem and the solution.
[x] The description mentions which forms of testing were done and the testing seems reasonable.
[x] Every function/class/actor that was touched is reasonably well documented.
For Release-Branches
If this PR is made against a release-branch, please also check the following:
[ ] This change/bugfix is a cherry-pick from the next younger branch (younger release-branch or main if this is the youngest branch)
[ ] There is a good reason why this PR needs to go into a release branch and this reason is documented (either in the description above or in a linked GitHub issue)
In cases where multiple operator instances are managing the same FDB cluster, like in the multi-dc setup, there can be a delay between a change in the coordinators and the operator instance updating the ConfigMap and all related resources. Especially in cases where only pods in a single dc are failing and the other operator instances are not receiving any events.
Code-Reviewer Section
The general pull request guidelines can be found here.
Please check each of the following things and check all boxes before accepting a PR.
For Release-Branches
If this PR is made against a release-branch, please also check the following:
release-branch
ormain
if this is the youngest branch)