🌱 Deprecate MHC MaxUnhealthy & UnhealthyRange fields

[sbueringer]

Signed-off-by: Stefan Büringer [email protected]

What this PR does / why we need it:

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Part of #10722

[sbueringer]

@enxebre / @vincepri WDYT?

[sbueringer]

cc @fabriziopandini @chrischdi

[enxebre]

no objections here to deprecate. My only concern before actually drop them in future is to make sure don't break any consumer where scalable resources might be decoupled from the short-circuiting remediation group as enabled by these fields today. E.g. there are MSs per az but one single common maxUnavailable budget for them.

[chrischdi]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 4205bd232e8cebd14aaf2c6101c9468d3213d13a

[fabriziopandini]

My only concern before actually drop them in future is to make sure don't break any consumer where scalable resources might be decoupled from the short-circuiting remediation group as enabled by these fields today. E.g. there are MSs per az but one single common maxUnavailable budget for them.

That's an interesting note.
Might be what we need is to be more explicit about the fact that those fields are about short-circuiting remediation (e.g by moving them in a sub struct + amending documentation)
(copied the same comment on the issue as well)

Considering that in both cases (removal or renaming) we need to go through deprecation of current fields
/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fabriziopandini

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:

• OWNERS [fabriziopandini]

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