Add optional hook for operator specific status modifications

[rashmigottipati]

Description

This PR adds an optional hook mechanism to StatusSyncer that allows operators to modify their ClusterOperator status before the update request is send to API server. The hook receives both the original status (reconcile start) and the mutated status (done by the reconcile logic), enabling operators informed decisions about additional tweaks, i.e. version that is going to send to API server.

Changes:

• Add ClusterOperatorStatusHook function type
• Add WithBeforeStatusUpdateHook() builder method
• Hook is invoked in Sync() after standard status logic completes, before the API update

Motivation

Operators sometimes need custom status logic such as detecting version changes during cluster upgrades. This usually requires comparing the target version (from environment) against the current version (in ClusterOperator status). Without access to the original status from etcd, operators cannot reliably detect these transitions. This hook provides a generic mechanism for operators to implement such custom logic.

Co-authored-by: Predrag Knezevic pknezevi@redhat.com

[rashmigottipati]

/hold

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Details

Needs approval from an approver in each of these files:

• pkg/operator/OWNERS

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

[rashmigottipati]

/unhold

[grokspawn]

Do you have an example PR we could use as an illustration of how this is utilized to achieve consistent upgrade signal?

[openshift-ci]

@rashmigottipati: all tests passed!

Full PR test history. Your PR dashboard.

Details

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.

[jsafrane]

Example of usage: openshift/cluster-olm-operator#169

[jsafrane]

I talked to @rashmigottipati and @pedjak, this is not a good solution how to fix an operator not setting Progressing=true during upgrade.

With the last test changes, operators are allowed to stay Progressing=false if the operand image is the same as before, e.g. during upgrade between two close versions.

This PR has a good code, anyone can reopen it if they find a good reason to have hooks in the StatusController. Flipping Progressing because a tests expects so was not good enough - we fixed the test instead.

[p0lyn0mial]

I talked to @rashmigottipati and @pedjak, this is not a good solution how to fix an operator not setting Progressing=true during upgrade.

With openshift/origin#30626, operators are allowed to stay Progressing=false if the operand image is the same as before, e.g. during upgrade between two close versions.

This PR has a good code, anyone can reopen it if they find a good reason to have hooks in the StatusController. Flipping Progressing because a tests expects so was not good enough - we fixed the test instead.

Thanks for the update. I’m going to close the PR then. As you wrote, it can be reopened when we find a good reason to have hooks in the StatusController.

/close

[openshift-ci]

@p0lyn0mial: Closed this PR.

Details

In response to this:

I talked to @rashmigottipati and @pedjak, this is not a good solution how to fix an operator not setting Progressing=true during upgrade.

With openshift/origin#30626, operators are allowed to stay Progressing=false if the operand image is the same as before, e.g. during upgrade between two close versions.

This PR has a good code, anyone can reopen it if they find a good reason to have hooks in the StatusController. Flipping Progressing because a tests expects so was not good enough - we fixed the test instead.

Thanks for the update. I’m going to close the PR then. As you wrote, it can be reopened when we find a good reason to have hooks in the StatusController.

/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.