Add generic resource patches - #2337
Conversation
Signed-off-by: kahirokunn <okinakahiro@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: kahirokunn The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2337 +/- ##
==========================================
+ Coverage 63.89% 65.49% +1.59%
==========================================
Files 55 56 +1
Lines 2479 2614 +135
==========================================
+ Hits 1584 1712 +128
+ Misses 776 771 -5
- Partials 119 131 +12 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
/ok-to-test |
|
/test integration-tests-multicluster |
|
@dsimansk Hi ✋ PTAL. Thank you 🙏 |
Summary
This adds a general-purpose
spec.patchesmechanism toKnativeServingandKnativeEventing.It covers the long tail of customizations that the Operator does not expose today, without requiring a dedicated API field and transformer for every use case. Patches are applied to the final generated resources, so the same mechanism works for core Serving and Eventing resources, optional Ingress and Source resources, extensions, and
additionalManifests.Existing custom resources are unaffected when
spec.patchesis empty.Motivation
The Operator already provides typed overrides for common settings. Those remain the preferred interface because they are discoverable and can be validated as part of the API.
However, Kubernetes resources have many fields that are useful only in particular environments. Adding each one to the Operator API would require more API surface, transformation code, generated CRDs, and tests.
spec.patchesprovides an escape hatch for those cases while keeping the common paths typed.Proposed Changes
spec.patchesto bothKnativeServingandKnativeEventing.namespacecan disambiguate otherwise identical targets.apiVersion,kind,metadata.name, ormetadata.namespace.$patch: deletefor removing a generated resource from the desired manifest.The full usage guide is in
docs/resource-patches.md.Usage
For example, this changes the rolling update strategy of the Serving controller, which does not need a dedicated Operator API field:
Targets use the final
apiVersion,kind,name, and optionalnamespaceof the generated resource. A missing or ambiguous target fails reconciliation so that stale patches are visible during upgrades.The usage guide also includes an external autoscaler example: deleting a bundled HPA and removing
spec.replicasfrom its Deployment lets a controller such as KEDA manage scaling without the Operator restoring those fields.Release Note