Merge pull request kubernetes#3861 from tallclair/webhook-predicates

KEP-3716: (Match Conditions) mark implementable + cleanup

Author: k8s-ci-robot

keps/sig-api-machinery/3716-webhook-predicates/README.md renamed to keps/sig-api-machinery/3716-admission-webhook-match-conditions/README.md

@@ -23,6 +23,9 @@
       - [Integration tests](#integration-tests)
       - [e2e tests](#e2e-tests)
   - [Graduation Criteria](#graduation-criteria)
+    - [Alpha](#alpha)
+    - [Beta](#beta)
+    - [GA](#ga)
   - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)
   - [Version Skew Strategy](#version-skew-strategy)
 - [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire)
@@ -214,8 +217,8 @@ type ValidatingWebhook struct {
   // for a request to be sent to this webhook. All conditions in the list must evaluate to TRUE for
   // the request to be matched.
   // +optional
-	// +patchMergeKey=name
-	// +patchStrategy=merge
+  // +patchMergeKey=name
+  // +patchStrategy=merge
   MatchConditions []MatchCondition `json:"matchConditions,omitempty"`
 }
 
@@ -339,116 +342,48 @@ implementing this enhancement to ensure the enhancements have also solid foundat
 
 ##### Unit tests
 
-<!--
-In principle every added code should have complete unit test coverage, so providing
-the exact set of tests will not bring additional value.
-However, if complete unit test coverage is not possible, explain the reason of it
-together with explanation why this is acceptable.
--->
-
-<!--
-Additionally, for Alpha try to enumerate the core package you will be touching
-to implement this enhancement and provide the current unit coverage for those
-in the form of:
-- <package>: <date> - <current test coverage>
-The data can be easily read from:
-https://testgrid.k8s.io/sig-testing-canaries#ci-kubernetes-coverage-unit
-
-This can inform certain test coverage improvements that we want to do before
-extending the production code to implement this enhancement.
--->
-
-- `<package>`: `<date>` - `<test coverage>`
+TBD - unit tests will be added as this feature is implemented.
 
 ##### Integration tests
 
-<!--
-This question should be filled when targeting a release.
-For Alpha, describe what tests will be added to ensure proper quality of the enhancement.
-
-For Beta and GA, add links to added tests together with links to k8s-triage for those tests:
-https://storage.googleapis.com/k8s-triage/index.html
--->
+Test cases to add:
 
-- <test>: <link to test coverage>
+- [ ] Feature gate enablement / disablement is a no-op when no `matchConditions` are set
+- [ ] Feature gate enablement / disablement works as expected when `matchConditions` are set
+- [ ] Single match condition:
+    - [ ] Request out of scope without `matchConditions`
+    - [ ] Request in scope without `matchConditions`, but not matching
+    - [ ] Request in scope without `matchConditions`, and also matching
+- [ ] Multiple match conditions, covering the same cases as the single-condition case
 
 ##### e2e tests
 
-<!--
-This question should be filled when targeting a release.
-For Alpha, describe what tests will be added to ensure proper quality of the enhancement.
-
-For Beta and GA, add links to added tests together with links to k8s-triage for those tests:
-https://storage.googleapis.com/k8s-triage/index.html
-
-We expect no non-infra related flakes in the last month as a GA graduation criteria.
--->
+We will test the edge cases mostly in integration tests and unit tests.
 
-- <test>: <link to test coverage>
+Once the feature is default enabled in beta, a single E2E test covering hte single-match-condition
+cases outlined above will be added.
 
 ### Graduation Criteria
 
-<!--
-**Note:** *Not required until targeted at a release.*
-
-Define graduation milestones.
-
-These may be defined in terms of API maturity, [feature gate] graduations, or as
-something else. The KEP should keep this high-level with a focus on what
-signals will be looked at to determine graduation.
-
-Consider the following in developing the graduation criteria for this enhancement:
-- [Maturity levels (`alpha`, `beta`, `stable`)][maturity-levels]
-- [Feature gate][feature gate] lifecycle
-- [Deprecation policy][deprecation-policy]
-
-Clearly define what graduation means by either linking to the [API doc
-definition](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-versioning)
-or by redefining what graduation means.
-
-In general we try to use the same stages (alpha, beta, GA), regardless of how the
-functionality is accessed.
-
-[feature gate]: https://git.k8s.io/community/contributors/devel/sig-architecture/feature-gates.md
-[maturity-levels]: https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions
-[deprecation-policy]: https://kubernetes.io/docs/reference/using-api/deprecation-policy/
-
-Below are some examples to consider, in addition to the aforementioned [maturity levels][maturity-levels].
-
 #### Alpha
 
-- Feature implemented behind a feature flag
-- Initial e2e tests completed and enabled
+- Feature implemented behind `AdmissionWebhookMatchConditions` feature flag
+- [Integration tests](#integration-tests) implemented
 
 #### Beta
 
-- Gather feedback from developers and surveys
-- Complete features A, B, C
-- Additional tests are in Testgrid and linked in KEP
-
-#### GA
-
-- N examples of real-world usage
-- N installs
-- More rigorous forms of testing—e.g., downgrade tests and scalability tests
-- Allowing time for feedback
+- Add E2E test coverage
+- Resolve resource constraints validation
 
-**Note:** Generally we also wait at least two releases between beta and
-GA/stable, because there's no opportunity for user feedback, or even bug reports,
-in back-to-back releases.
-
-**For non-optional features moving to GA, the graduation criteria must include
-[conformance tests].**
-
-[conformance tests]: https://git.k8s.io/community/contributors/devel/sig-architecture/conformance-tests.md
+<<[UNRESOLVED resource constraints ]>>
+Additional beta requirements TBD
+<<[/UNRESOLVED]>>
 
-#### Deprecation
+#### GA
 
-- Announce deprecation and support policy of the existing flag
-- Two versions passed since introducing the functionality that deprecates the flag (to address version skew)
-- Address feedback on usage/changed behavior, provided on GitHub issues
-- Deprecate the flag
--->
+<<[UNRESOLVED resource constraints ]>>
+GA requirements TBD
+<<[/UNRESOLVED]>>
 
 ### Upgrade / Downgrade Strategy
 

keps/sig-api-machinery/3716-webhook-predicates/kep.yaml renamed to keps/sig-api-machinery/3716-admission-webhook-match-conditions/kep.yaml

@@ -5,7 +5,7 @@ authors:
 owning-sig: sig-api-machinery
 participating-sigs:
   - sig-auth
-status: provisional
+status: implementable
 creation-date: 2023-01-09
 reviewers:
   - jpbetz
@@ -14,6 +14,7 @@ reviewers:
 approvers:
   - jpbetz
   - deads2k
+  - lavalamp
 
 ##### WARNING !!! ######
 # prr-approvers has been moved to its own location