cli-utils
cli-utils copied to clipboard
feat: allow disabling/overriding ObjectFilter in status watcher
With the addition of Filters to the DefaultStatusWatcher it is now possible to apply server-side filtering via labels/fields. This PR allows dropping or overriding client-side filtering with a custom ObjectFilter. In our case we are making sure that every resource in the inventory will contain a static label that can be used for server-side filtering and further client-side filtering is obsolete.
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: floreks Once this PR has been reviewed and has the lgtm label, please assign mortent for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
What's the benefit of using a custom object filter?
The built-in filter filters by ID from a map, so it's pretty efficient, just a hashtable lookup. It shouldn't cause any real performance impact.
There might not be many use cases for the custom implementation of ObjectFilter. Being able to disable it completely when relying on server-side filtering is what I was looking for. If that would be something you would be interested in, let me know and I will adjust the code.
PS. From what I can see current AllowListObjectFilter is simply going through the array and doing a struct comparison.
https://github.com/kubernetes-sigs/cli-utils/blob/4d57e6e23edac29f2ea3ae9aa8b0ff0a85fc01cc/pkg/kstatus/watcher/object_filter.go#L27-L30
https://github.com/kubernetes-sigs/cli-utils/blob/4d57e6e23edac29f2ea3ae9aa8b0ff0a85fc01cc/pkg/object/objmetadata_set.go#L56-L62
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle stale - Close this PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle rotten - Close this PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten