Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Query resources in current namespace by default #18

Closed
ahmetb opened this issue Jan 7, 2020 · 3 comments · Fixed by #22
Closed

Query resources in current namespace by default #18

ahmetb opened this issue Jan 7, 2020 · 3 comments · Fixed by #22

Comments

@ahmetb
Copy link
Owner

ahmetb commented Jan 7, 2020

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:

  • fails to query api X, because user has access to X in namespace1, but not in namespace2
  • takes too long to enumerate all APIs across all namespaces (Long execution time #16)

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).

@ahmetb
Copy link
Owner Author

ahmetb commented Jan 8, 2020

Anyone willing to take this on?

@feloy
Copy link
Collaborator

feloy commented Jan 8, 2020

Anyone willing to take this on?

☝️ I can work on this

@ahmetb
Copy link
Owner Author

ahmetb commented Jan 8, 2020

Please!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants