OCPBUGS-48276: Make the revision controller report degraded on error

[deads2k]

This makes the error handling slightly easier, keeps the retry on error logic, leaves the requeue on self-modification we rely upon.

This doesn't introduce VAP to prevent writes to "immutable" configmaps and secrets, but I'm open to doing that to prevent stale caches from creating unstable and inconsistent revisions.

new

  - apiVersion: operator.openshift.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:status:
        f:conditions:
          k:{"type":"RevisionControllerDegraded"}:
            .: {}
            f:lastTransitionTime: {}
            f:reason: {}
            f:status: {}
            f:type: {}
    manager: RevisionController-reportDegraded
    operation: Apply
    subresource: status
    time: "2025-01-10T20:20:59Z"
  - apiVersion: operator.openshift.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:status:
        f:latestAvailableRevision: {}
    manager: kube-apiserver-RevisionController
    operation: Apply
    subresource: status
    time: "2025-01-10T20:30:45Z"

old

  - apiVersion: operator.openshift.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:status:
        f:conditions:
          k:{"type":"RevisionControllerDegraded"}:
            .: {}
            f:lastTransitionTime: {}
            f:status: {}
            f:type: {}
        f:latestAvailableRevision: {}
    manager: kube-apiserver-RevisionController
    operation: Apply
    subresource: status
    time: "2025-01-11T07:38:04Z"

[deads2k]

requires passing proof in openshift/cluster-kube-apiserver-operator#1783 that confirms the low level condition names are the same between 4.18 and master.

[benluddy]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: benluddy, deads2k

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

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/operator/revisioncontroller/OWNERS [deads2k]

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

[benluddy]

I think this patch will fix the following scenario that causes the revision controller to attempt to decrease LatestAvailableRevision:

1. Observe RV=N LatestAvailable=X Degraded=False
2. Write RV=N+1 LatestAvailable=X+1 Degraded=False
3. Observe RV=N LatestAvailable=X Degraded=False
4. Write RV=N+2 LatestAvailable=X Degraded=True

/retitle OCPBUGS-48276: Make the revision controller report degraded on error

[openshift-ci-robot]

@deads2k: This pull request references Jira Issue OCPBUGS-48276, which is invalid:

• expected the bug to target the "4.19.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

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

In response to this:

This makes the error handling slightly easier, keeps the retry on error logic, leaves the requeue on self-modification we rely upon.

This doesn't introduce VAP to prevent writes to "immutable" configmaps and secrets, but I'm open to doing that to prevent stale caches from creating unstable and inconsistent revisions.

new

 - apiVersion: operator.openshift.io/v1
   fieldsType: FieldsV1
   fieldsV1:
     f:status:
       f:conditions:
         k:{"type":"RevisionControllerDegraded"}:
           .: {}
           f:lastTransitionTime: {}
           f:reason: {}
           f:status: {}
           f:type: {}
   manager: RevisionController-reportDegraded
   operation: Apply
   subresource: status
   time: "2025-01-10T20:20:59Z"
 - apiVersion: operator.openshift.io/v1
   fieldsType: FieldsV1
   fieldsV1:
     f:status:
       f:latestAvailableRevision: {}
   manager: kube-apiserver-RevisionController
   operation: Apply
   subresource: status
   time: "2025-01-10T20:30:45Z"

old

 - apiVersion: operator.openshift.io/v1
   fieldsType: FieldsV1
   fieldsV1:
     f:status:
       f:conditions:
         k:{"type":"RevisionControllerDegraded"}:
           .: {}
           f:lastTransitionTime: {}
           f:status: {}
           f:type: {}
       f:latestAvailableRevision: {}
   manager: kube-apiserver-RevisionController
   operation: Apply
   subresource: status
   time: "2025-01-11T07:38:04Z"

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]

/jira refresh

[openshift-ci-robot]

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

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.19.0) matches configured target version for branch (4.19.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @wangke19

In response to this:

/jira refresh

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]

/cherry-pick release-4.18

[openshift-cherrypick-robot]

@benluddy: once the present PR merges, I will cherry-pick it on top of release-4.18 in a new PR and assign it to you.

In response to this:

/cherry-pick release-4.18

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.

[openshift-ci]

@deads2k: all tests passed!

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

[openshift-ci-robot]

@deads2k: Jira Issue OCPBUGS-48276: All pull requests linked via external trackers have merged:

• openshift/library-go#1918

Jira Issue OCPBUGS-48276 has been moved to the MODIFIED state.

In response to this:

This makes the error handling slightly easier, keeps the retry on error logic, leaves the requeue on self-modification we rely upon.

This doesn't introduce VAP to prevent writes to "immutable" configmaps and secrets, but I'm open to doing that to prevent stale caches from creating unstable and inconsistent revisions.

new

 - apiVersion: operator.openshift.io/v1
   fieldsType: FieldsV1
   fieldsV1:
     f:status:
       f:conditions:
         k:{"type":"RevisionControllerDegraded"}:
           .: {}
           f:lastTransitionTime: {}
           f:reason: {}
           f:status: {}
           f:type: {}
   manager: RevisionController-reportDegraded
   operation: Apply
   subresource: status
   time: "2025-01-10T20:20:59Z"
 - apiVersion: operator.openshift.io/v1
   fieldsType: FieldsV1
   fieldsV1:
     f:status:
       f:latestAvailableRevision: {}
   manager: kube-apiserver-RevisionController
   operation: Apply
   subresource: status
   time: "2025-01-10T20:30:45Z"

old

 - apiVersion: operator.openshift.io/v1
   fieldsType: FieldsV1
   fieldsV1:
     f:status:
       f:conditions:
         k:{"type":"RevisionControllerDegraded"}:
           .: {}
           f:lastTransitionTime: {}
           f:status: {}
           f:type: {}
       f:latestAvailableRevision: {}
   manager: kube-apiserver-RevisionController
   operation: Apply
   subresource: status
   time: "2025-01-11T07:38:04Z"

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-cherrypick-robot]

@benluddy: new pull request created: #1920

In response to this:

/cherry-pick release-4.18

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.