You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From controller examples like Kubernetes Deployment, Knative, Agones, etc. it's fair to assume that resources don't often create child resources in other namespaces.
Proposed solution
When kubectl tree is querying child objects of a specified object:
we should query only "namespaced" objects in the same namespace as the specified object as the new default
we should offer --all-namespaces option to retain the current behavior (e.g. query all objects in all API groups –both namespaced and non-namespaced)
This addresses:
slowness when used with large clusters with too many objects
allow an escape hatch for the current behavior to still exist
allow plugin to work when user has (full-) access to only some namespaces
It would likely work by refactorying query method to be namespace-scoped (query only namespaced APIs in the specified namespace) OR global-scoped (query both namespaced & non-namespaced APIs without specifying a namespace limitation, i.e. what we do today).
The text was updated successfully, but these errors were encountered:
This came up in #9, #14 and #16.
Right now (v0.3.x) we are querying ALL objects in ALL api groups (without any namespace limitation). This has several problems:
From controller examples like Kubernetes Deployment, Knative, Agones, etc. it's fair to assume that resources don't often create child resources in other namespaces.
Proposed solution
When
kubectl tree
is querying child objects of a specified object:--all-namespaces
option to retain the current behavior (e.g. query all objects in all API groups –both namespaced and non-namespaced)This addresses:
It would likely work by refactorying query method to be namespace-scoped (query only namespaced APIs in the specified namespace) OR global-scoped (query both namespaced & non-namespaced APIs without specifying a namespace limitation, i.e. what we do today).
The text was updated successfully, but these errors were encountered: