Add paused annotation for MachineHealthCheck

[alexander-demicev]

No description provided.

[JoelSpeed]

Do we want to call this MHCPausedAnnotation? I know it's only used for MHC at the moment but that does restrict us in the future if we wanted to use this elsewhere, WDYT?

[alexander-demicev]

I named it MHCPausedAnnotation because no other Machine API components support paused state, a more generic name can be confusing now.

[JoelSpeed]

I guess in the future we can rename it to something more generic, but we will have to keep this constant around, deprecate it, etc. I'm fine with this for now so long as API folks are

[JoelSpeed]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: alexander-demichev, JoelSpeed
To complete the pull request process, please assign deads2k after the PR has been reviewed.
You can assign the PR to them by writing /assign @deads2k in a comment when ready.

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

Details

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

[deads2k]

is the machine health check controller an upstream controller or downstream one? I thought it was a downstream controller that watched MachineHealthCheck.machine.openshift.io. If it is a downstream controller and a downstream API, this seems like a good choice for either

1. a spec field
2. handling by simply deleting the machinehealthcheck

[JoelSpeed]

The machinehealthcheck is a fork of the upstream controller which is currently feature paired. We do have our own CRDs but they match the upstream identically at the moment.

The paused feature is something we picked from their implementation and we decided, to avoid potential future discrepancies between OCP and HyperShift, to keep the same annotation.

This was shipped in 4.9 and so I don't think we want to make a change to this now, though I appreciate based on our prior conversations about API compatibility that we should have made this a first class field when we backported it

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closed this PR.

Details

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/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/test-infra repository.