feat: Add filterRules schema to WorkspaceKind CRD#1263
Conversation
google-oss-prow
Bot
added
the
area/controller
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
google-oss-prow
Bot
added
area/v2
…tibility selectors Add a new optional spec.filterRules[] field to the WorkspaceKind CRD to store admin-defined rules that downstream consumers (the backend API server) use to dynamically filter which WorkspaceKinds, imageConfig values, and podConfig values are visible or allowed in a given context. The controller only persists and validates these rules; it does not evaluate them. - add FilterRule types with kubebuilder validation markers - regenerate CRD manifests and DeepCopy methods - add webhook validation for label selectors, at-least-one-effect, and scope-appropriate match types - add unit tests covering all scope types, match combinations, and invalid configurations - add filterRules examples to the 3 sample WorkspaceKinds Closes: kubeflow#690 Signed-off-by: Gang Li <ganglica@google.com>
c7cf9d0 to
19f2a91
Compare
|
/ok-to-test |
|
@gangli113: Cannot trigger testing until a trusted user reviews the PR and leaves an DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
1 participant
Description
Adds a new optional spec.filterRules[] field to the WorkspaceKind CRD to store admin-defined
rules that downstream consumers (the backend API server) use to dynamically filter which
WorkspaceKinds, imageConfig values, and podConfig values are visible or allowed in a given
context. The controller does not evaluate these rules — it only persists and validates them.
Schema follows the approved proposal in #683.
Changes
Closes #690