[release-4.19] Throttle resourcesynccontroller on pairs with dual writers.

[benluddy]

Writes from the instance of resourcesynccontroller in the operator can contend with writes from the recovery sidecar's instance of the same controller. This is a preexisting issue, and the controller doesn't have an effective way to limit resync frequency. Adding some fixed latency to each sync in this way sets an upper bound on the churn rate when the two instances get into a feedback cycle.

The separate issues that can create a feedback cycle (e.g. the resourcesynccontroller degraded operator status condition is shared by both instances) should be separately addressed "soon".

#882

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: benluddy
Once this PR has been reviewed and has the lgtm label, please assign deads2k for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

@benluddy: This pull request references Jira Issue OCPBUGS-60682, which is valid. The bug has been moved to the POST state.

7 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.19.z) matches configured target version for branch (4.19.z)
• bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)
• release note text is set and does not match the template
• dependent bug Jira Issue OCPBUGS-60473 is in the state Closed (Done), which is one of the valid states (VERIFIED, RELEASE PENDING, CLOSED (ERRATA), CLOSED (CURRENT RELEASE), CLOSED (DONE), CLOSED (DONE-ERRATA))
• dependent Jira Issue OCPBUGS-60473 targets the "4.20.0" version, which is one of the valid target versions: 4.20.0
• bug has dependents

Requesting review from QA contact:
/cc @wangke19

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

Writes from the instance of resourcesynccontroller in the operator can contend with writes from the recovery sidecar's instance of the same controller. This is a preexisting issue, and the controller doesn't have an effective way to limit resync frequency. Adding some fixed latency to each sync in this way sets an upper bound on the churn rate when the two instances get into a feedback cycle.

The separate issues that can create a feedback cycle (e.g. the resourcesynccontroller degraded operator status condition is shared by both instances) should be separately addressed "soon".

#882

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[benluddy]

/close

[openshift-ci-robot]

@benluddy: No Jira issue is referenced in the title of this pull request.
To reference a jira issue, add 'XYZ-NNN:' to the title of this pull request and request another refresh with /jira refresh.

In response to this:

Writes from the instance of resourcesynccontroller in the operator can contend with writes from the recovery sidecar's instance of the same controller. This is a preexisting issue, and the controller doesn't have an effective way to limit resync frequency. Adding some fixed latency to each sync in this way sets an upper bound on the churn rate when the two instances get into a feedback cycle.

The separate issues that can create a feedback cycle (e.g. the resourcesynccontroller degraded operator status condition is shared by both instances) should be separately addressed "soon".

#882

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

@benluddy: Closed this PR.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.