Repository navigation
Preserve Helm release defaults while retiring two legacy mutation policies #5357
Description
🤖 Generated by the Agentic Engineer
Problem and impact
The two remaining Flux defaults helm-release-enable-tests and helm-release-remediation-retries still use the retiring ClusterPolicy API. They supply opted-in Helm releases with test execution and bounded remediation settings. Removing them during the Kyverno migration would silently change new or updated releases. The CRD-install default is already a MutatingPolicy and is outside this rewrite.
Evidence and bounded delivery
At Platform main 953e9ce62682b4605e3014b54c45abc264fd655e, both policies have no dedicated fixtures. New fixtures now pass against their original ClusterPolicies using the repository's exact Kyverno 1.19.1 pin. They cover absent and partially populated settings, explicit settings that the policies override, preservation of unrelated fields, unlabelled/disabled resources, another resource kind, and updates that remove or disable a previously enabled label. Six independent ablations of the old rules are rejected for the expected mutation or evaluation defect.
Migrate only these two defaults, using the already established JSON-patch pattern for custom HelmRelease resources. Keep their names, opt-in selectors, incoming-object scope, failure behavior and resulting objects. Constant assignments and conditional parent creation must be harmless during temporary overlap with their old ClusterPolicies and with the CRD default. This is a delivery child of #4997; the other mutation policies and Kyverno upgrade remain separate work.
Acceptance criteria
- Preserve recorded old-policy baseline and negative-control receipts. The new policies pass the same fixture expectations and byte-identical expected objects on Kyverno 1.19.1; only the obsolete rule-name references change in the fixture declarations.
- Both resources become MutatingPolicy in the same reviewed change that removes their old kinds. Incoming disabled/removed labels do not re-enable the defaults on UPDATE. Preserve unrelated settings and the existing failure policy.
- Show repeated application and composition with the existing CRD-install default produce the same object in every order. The fixture-evaluation guard must reject invalid or unevaluated policies.
- All required policy tests, fixture evaluation, manifest/layer validation and independent review pass; complete the protected deployment and merge.
- After deployment, verify both new policies are ready and the corresponding ClusterPolicies are gone. Observe the preserved defaults through authorized admission evaluation and existing workload readback. Keep Migrate the workload-default and HelmRelease mutation ClusterPolicies to MutatingPolicy #4997 open for its remaining policies and final aggregate acceptance.
Priority rationale
High priority / Medium effort, Risk reduction. This is an independently deployable part of the already-Ready, High-priority policy migration. It protects existing release behavior rather than enabling a new service or changing paid capacity. No local cluster or controller upgrade is required.
Reference: Kyverno MutatingPolicy documentation.
Post-deployment acceptance — 26 October
PR #5360 merged the evaluated head 3ed20e35b50ede3a17f6a319cc16d3445fc69e38 as e2d6abb2f31f33f6c67cfaffec97229d966c43cf. Its protected merge-group CI passed, including the production deployment. Read-only follow-up confirms both replacement policies exist and both old ClusterPolicies are absent. Existing opted-in HelmReleases retain the expected test and remediation values.
Acceptance is still incomplete: both replacements report ready: false because their reporting permission condition is not satisfied. This is the wildcard reporting boundary tracked in #4929; no broader access, reporting suppression or admission-scope change was applied. Existing stored workload values do not prove a fresh admission evaluation. That live admission check also remains outstanding.
The automatic issue closure is therefore reopened. Keep the final acceptance criterion and parent #4997 open until reporting readiness and authorized admission evidence are collected.
Blocker: #4929 | upstream | last-verified 2026-10-26: Protected merge is complete; live reporting readiness remains false for both migrated policies. Preserve admission scope and least privilege while resolving the reporting boundary.
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Effort
Projects
- StatusShow more project fields🫴 Ready
Activity
chore: agent-claim #5357 nonce=216b1b2108f887676eed5dc9fe9c50c1
chore: agent-claim #5357 nonce=dd64a70e4113cf0d2213820c3952115e
devantler commentedon Nov 1, 2026
Fresh read-only follow-up found a stored-object conformance counterexample: an opted-in infrastructure release retains pre-default retry settings and has no test configuration. The declared admission/background scope difference explains why admission cannot supply those defaults there. This needs a bounded source-conformance assessment while preserving the existing admission exclusions and reporting access boundary; it is separate from the reporting repair in #4929.
The two named replacement-policy reads currently expose no readiness status or conditions, so this observation provides no fresh readiness clearance. Keep the final acceptance criterion open. No access grant, policy scope, warning filter or runtime object was changed.