Application of `selector`s locally scales badly
- In places the UI fetches all of a resource and then filters by selector
- see shell/utils/selector.js, in particular matches and matching
- these are used in specific places but also findMatching if all resources have been fetched
- Fetching all of a resource is bad and we need to fix this
- Need to look at each use case and find a better way
- in places we could just make an api request with ~
labelSelector~ newfilter=metadata.labelinstead - in other places individual resources each apply a selector to all resources (we couldn't just make a single request with a single selector)
- in places we could just make an api request with ~
- Notable Parts
- findMatching action
- vue store action that will make an API request with the given selector
- matching getter
- vue store getter that will provide resources from cache that match the given selector
- MatchExpressions
- Component that creates a selector
- ResourceSelector
- Wraps MatchExpression, showing resources that match it's selector
- selector.js helper functions
- matches - does the given resource match the selector
- matching - apply the given selector to the given resources
- findMatching action
- Specific cases
- findMatching action (with selector)
- shell/plugins/dashboard-store/resource-class.js
- _findRelationship. selector from _relationshipsFor --> metadata.relationships[].selector
- only used by shell/models/cis.cattle.io.clusterscan.js to find owned cluster scan CIS reports (cis.cattle.io.clusterscanreport)
- Action: Remove generic handling
- Action: Implement using API + selector
- shell/pages/c/_cluster/longhorn/index.vue
- services with label app=longhorn-ui
- Action: Implement with API + label filtering
- services with label app=longhorn-ui
- shell/pages/c/_cluster/uiplugins/CatalogList/CatalogUninstallDialog.vue
- deployment, service, helm repo with specific label
- Action: Implement with API + label filtering
- deployment, service, helm repo with specific label
- shell/plugins/steve/subscribe.js
- resyncing values (forced new request)
- also uses
matchinggetter --> selector.js matching - Action: Depends on clusterscan above
- shell/plugins/dashboard-store/resource-class.js
- selector.js matches
- shell/components/SortableTable/filtering.js handleStringSearch
- converts sortable table search string to a selector, applies checks row
- Action: None
- shell/detail/workload/index.vue findMatchingServices
- workload detail page. finds services associated with pods in a workload (service.spec.selector)
- services shown on page
- Action: Implement using API + selector
- used to find ingresses (also shown on page)
- Action: Implement using API + selector
- services shown on page
- workload detail page. finds services associated with pods in a workload (service.spec.selector)
- shell/models/workload.js pods
- find pods associated with workload (finds relationships that are pods, applies that selector to pods)
- Action: Implement using API + selector
- workload detail page
- pod restarts
- pod guages
- job guages
- services list
- pods list
- find pods associated with workload (finds relationships that are pods, applies that selector to pods)
- shell/components/SortableTable/filtering.js handleStringSearch
- selector.js matching
- shell/components/form/ResourceSelector.vue updateMatchingResources
- ties in a MatchExpress component with a ResourceTable
- only used by shell/edit/policy.poddisruptionbudget.vue
- Action: Implement using API + selector
- shell/edit/service.vue updateMatchingPods
- finds pods for the services matching service's value.spec.selector
- Action: Implement using API + selector
- finds pods for the services matching service's value.spec.selector
- shell/edit/networking.k8s.io.networkpolicy/index.vue
- finds pods for policy matching selector from MatchExpressions
- Action: Implement using API + selector
- finds pods for policy matching selector from MatchExpressions
- shell/edit/networking.k8s.io.networkpolicy/PolicyRuleTarget.vue getMatchingPods
- find pods for rule matching selector from MatchExpressions
- Action: Implement using API + selector
- find pods for rule matching selector from MatchExpressions
- shell/edit/networking.k8s.io.networkpolicy/PolicyRuleTarget.vue getMatchingNamespaces
- find namespaces for rule matching selector from MatchExpressions
- Action: Implement using API + selector
- find namespaces for rule matching selector from MatchExpressions
- shell/models/service.js pods
- find pods for service matching pod selector
- Action: Implement using API + selector
- find pods for service matching pod selector
- shell/models/workload.js
- find pods given workloads spec.selector (used for ssh to first running pod)
- Action: Implement using API + selector
- find pods given workloads spec.selector (used for ssh to first running pod)
- shell/components/form/ResourceSelector.vue updateMatchingResources
- findMatching action (with selector)
Fleet Specific (to be done in https://github.com/rancher/dashboard/issues/13946)
- shell/edit/fleet.cattle.io.clustergroup.vue updateMatchingClusters
- find clusters for cluster group mathing selector from MatchExpressions
- Action: Implement using API + selector
- find clusters for cluster group mathing selector from MatchExpressions
- shell/models/fleet.cattle.io.bundle.js targetClusters
- find clusters for cluster group selector
- Action: Implement using API + selector
- find clusters for cluster selector
- Action: Implement using API + selector
- find clusters for cluster group selector
- shell/models/fleet.cattle.io.clustergroup.js targetClusters
- find clusters for cluster group selector
- Action: Implement using API + selector
- find clusters for cluster group selector
- shell/models/fleet.cattle.io.gitrepo.js
- find clusters for cluster group selector
- Action: Implement using API + selector
- find clusters for cluster selector
- Action: Implement using API + selector
- find clusters for cluster group selector
Useful links
- https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#labelselector-v1-meta
- https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#list-and-watch-filtering
- https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#deploymentspec-v1-apps
Notes
- labelSelectors contain two parts
- matchExpression: key - operator (in, not in, less than, etc), - values
- matchLabel is shorthand for key - IN - values
- https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#labelselector-v1-meta
Edit: Updates with all cases
Implementation dependent on https://github.com/rancher/rancher/issues/46333
See https://github.com/rancher/rancher/issues/46333#issuecomment-2256175260
More complex / full labelSelector support will not be included in 2.10 and are out of scope of the above linked issue.
For this release we will disable the basic use cases of selects x or y, to be enabled with full labelSelector support post 2.10 (issue pending).
If more core use cases are discovered then the above can be reviewed
Edit: More use cases have been discovered (description updated)
@moio I've updated the issue including all the places where we apply fully selectors locally. There's quite a few.
There's a lot of work there to either
- Disable all the features - I would not like to say we're production ready if so
- Convert all usages to filter via API and not locally (requires full label selector api support)
@richard-cox: I agree this list looks too long to accept in a non-experimental version.
Disabling them while the feature is experimental does not make sense to me. Better to have a list of known regressions (or a shortlist of features expected to work) and actually address the underlying limitations.
I am adding full label selector API support to https://github.com/rancher/rancher/issues/46333.
We should be able to get back workload health indicators once this work is complete (see shell/list/workload.vue loadHeathResources)
Note - some affected places in code now reference this issue. ensure those are addressed when resolving this
Blocked on https://github.com/rancher/rancher/issues/46333
For the selectors under network policies, I'm just confused that there are 5 pods under the given namespace, but the UI says it matches 0 pods with the criteria. Is this a bug? Verified in
Rancher v2.12-659a3fe3ac0d6ff0654717dcbd3161391d1f5662-head Dashboard master bdce41a Rancher CLI v2.12.0-rc.1
VAI successfully filters out by selector in the API call
Under Pod Disruption Budget, if the selector is deleted, then it brakes the structure of the API call, so that it then gets a 422 status code, failing to re-displying the previous results for a given selector. This could be related to the failure to find the match under Network Policy. This needs investigation.
https://github.com/user-attachments/assets/7c5bc522-3a99-4d5c-8fdc-a30287677dd1
It seems like the selectors are not being queried
https://github.com/user-attachments/assets/74d64d14-936b-45e7-86ec-590f8ad46021
For the selectors under network policies, I'm just confused that there are 5 pods under the given namespace, but the UI says it matches 0 pods with the criteria.
It looks like that's expected. These are label selectors, so from the screenshot you were searching for a label named namespace with a value of cattle-system, as your resource will be created in the cattle-system (selected at top next to name) it also only looks at resources in that namespace
Under Pod Disruption Budget, if the selector is deleted, then it brakes the structure of the API call
It doesn't look like the selector is deleted. When clicking Remove the entire row should be removed. There could be a problem with the generic component that handles this
Update
It seems like the selectors are not being queried
that's another one that the label's are queried for one called ip with that value, rather than a column in the table called ip with that value
It might be worth reviewing https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
@IsaSih whilst investigating the second point i discovered a few things and made some updates. these are mostly how resources fetched by a request based on labelSelector filtering are updated. in some cases we want the ui to show the latest versions (detail pages and pods lists) and others not (show example result set when editing resource's labelSelectors).
overall this is ready to test again
Rancher version: v2.12.0-rc3
From the description in the PR https://github.com/rancher/dashboard/pull/12919#issue-2750940934 This is what I validated and is meeting the expectation. ✔️
- Workload based lists --> Health column should contain the correct pods (non-vai only)
- Deployment --> Detail Page --> action menu --> Execute Shell (comes up fine)
- Extensions --> Manage Extensions Catalogs --> Import Extension Catalog --> set hub.docker.io/rancher/ui-plugin-catalog:4.0.1 as Catalog Image Reference --> Load --> wait a few minutes + refresh --> Uninstall catalog --> open browser dev tools --> Uninstall --> three GET requests to will be made to deployments, services and clusterrepos followed by three DELETE
Extensions is only doing one GET, but all the resources created are removed with the three DELETE after it.
Tested the below scenarios on Rancher version: v2.12.0-rc3
- CIS Benchmark (now called Rancher Compliance) ✅
- CroneJob detail page -> Jobs resource list - found non blocker issue
The following was validated in v2.12.0-rc2. Works as expected:
The following pages now supporting pagination with real time querying by selectors
- Network Policy --> Create/Edit + Detail Pages
- Ingress/Egress Rules --> Add Rule --> Add allowed traffic source --> Rule types of Namespace Selector, Pod Selector and Namespace/Pod Selector types
- Selectors tab
- Pod Disruption Budgets --> Create/Edit + Detail Pages --> Selector tab Service
- Create/Edit + Detail Page --> Selectors tab
- Detail Page --> Pods List
- Workload (pod based) --> Detail Page
The following was validated in v2.12.0-rc3.
- Pods List
- Pod Restarts value in header detail section
- Scale up/down should result in correct gauges and pods in table Pods List --> refresh page --> Deployments List --> click on one --> Pods list should should be populated Deployment Detail page --> refresh --> Pods list should be populated