Summary
This is a sub-issue of #835 ("Remove deprecated ServerMaintenanceApprovalKey and backward-compatibility logic").
Before removing the deprecated ServerMaintenanceApprovalKey constant (value: metal.ironcore.dev/maintenance-approval) in the next major release, a webhook validation should be added to explicitly reject any ServerClaim create/update that still carries the old label or annotation key. This ensures consumers receive a clear, actionable error rather than experiencing silent failures when the key is eventually removed.
Problem
When ServerMaintenanceApprovalKey (metal.ironcore.dev/maintenance-approval) is removed without a webhook guard, any consumer still writing the old key will silently have their approval ignored — the maintenance will never proceed and no error will surface.
Proposed Solution
Implement a validating admission webhook for ServerClaim that:
- On create and update operations, inspects
metadata.annotations and metadata.labels.
- If either contains the deprecated key
metal.ironcore.dev/maintenance-approval, reject the request with a descriptive error message, e.g.:
ServerClaim uses deprecated maintenance approval key "metal.ironcore.dev/maintenance-approval"; please migrate to "metal.ironcore.dev/maintenance-approved"
Tasks
Context
- Deprecated constant:
ServerMaintenanceApprovalKey = metal.ironcore.dev/maintenance-approval (in api/v1alpha1/servermaintenance_types.go)
- New constant:
ServerMaintenanceApprovedLabelKey = metal.ironcore.dev/maintenance-approved
- Introduced/renamed in: PR
#830
- Deprecation tracking issue:
#831
- Parent cleanup issue:
#835
- Requested by:
@nagadeesh-nagaraja
Notes
This webhook guard should be shipped before the removal of the deprecated constant (tracked in #835) so that consumers have a clear migration window with explicit feedback.
Summary
This is a sub-issue of #835 ("Remove deprecated
ServerMaintenanceApprovalKeyand backward-compatibility logic").Before removing the deprecated
ServerMaintenanceApprovalKeyconstant (value:metal.ironcore.dev/maintenance-approval) in the next major release, a webhook validation should be added to explicitly reject anyServerClaimcreate/update that still carries the old label or annotation key. This ensures consumers receive a clear, actionable error rather than experiencing silent failures when the key is eventually removed.Problem
When
ServerMaintenanceApprovalKey(metal.ironcore.dev/maintenance-approval) is removed without a webhook guard, any consumer still writing the old key will silently have their approval ignored — the maintenance will never proceed and no error will surface.Proposed Solution
Implement a validating admission webhook for
ServerClaimthat:metadata.annotationsandmetadata.labels.metal.ironcore.dev/maintenance-approval, reject the request with a descriptive error message, e.g.:Tasks
ValidateCreate/ValidateUpdatecheck in theServerClaimwebhook (or create a new webhook if one does not already exist) that detects the presence ofmetal.ironcore.dev/maintenance-approvalin annotations and/or labelsmetal.ironcore.dev/maintenance-approvedContext
ServerMaintenanceApprovalKey=metal.ironcore.dev/maintenance-approval(inapi/v1alpha1/servermaintenance_types.go)ServerMaintenanceApprovedLabelKey=metal.ironcore.dev/maintenance-approved#830#831#835@nagadeesh-nagarajaNotes
This webhook guard should be shipped before the removal of the deprecated constant (tracked in #835) so that consumers have a clear migration window with explicit feedback.