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

Default to current namespace? (or via --ns) #33

Closed
rcoup opened this issue May 8, 2019 · 5 comments
Closed

Default to current namespace? (or via --ns) #33

rcoup opened this issue May 8, 2019 · 5 comments

Comments

@rcoup
Copy link

rcoup commented May 8, 2019

Currently kail with no arguments matches every pod in the cluster — personally I think this should be the current namespace, there's so many system pods and their logs aren't usually relevant to day to day application work. Not sure how you feel about changing that default?

Otherwise, it'd be nice for kail --ns (ie. with no namespace) to default to the current namespace. Currently, --ns matches all namespaces, and --ns= matches nothing.

@boz
Copy link
Owner

boz commented May 8, 2019

Hi @rcoup, thanks for the input!

I agree that the kube-system ns is distracting. That being said, kail is meant to be a simple "just give me the damn logs" utility; kubectl's --all-namespaces is particularly annoying to me.

I think something like the following would be a reasonable approach:

  • Ignore system namespaces: Add an --ignore-ns=... flag that defaults to (kube-system). Similar to the current --ignore flag.
  • Use "current" namespace: Add --current-ns=true|false flag.
  • Collect --ignore-ns, --current-ns, --ns, etc... values from environment variables.

Let me know if you have any thoughts on this.

Currently, --ns matches all namespaces, and --ns= matches nothing.

Thanks for pointing that out, these should have the same behavior.

@rcoup
Copy link
Author

rcoup commented May 9, 2019

We mostly use namespaces for logical app separation, so (virtually) everything relevant is in the same namespace. But I guess that can be different for everyone.

I'm not that keen on another flag for --current-ns. But everything is additive, I'd forgotten that, which would make a bare --ns trickier to implement. 👍

So:

  • kail -> {$all}-{$ignored}
  • kail --ns=foo -> {foo}
  • kail --ns=foo --ns=bar -> {foo} + {bar}
  • kail --current-ns -> {$current}
  • kail --current-ns --ns=foo -> {foo} + {$current}
  • --ignore-ns setting would only be used when --ns or --current-ns aren't specified (can't see it helps any other approach?)

@boz
Copy link
Owner

boz commented May 9, 2019

I'm not that keen on another flag for --current-ns.

Me neither, but if it's easy to use and not confusing, I'd go for it. At the end of the day, this can all be done with scripting, but it's nice to have some things baked in instead of this:

alias kailc='kail --ns $(kubectl config view -o jsonpath="{.contexts[?(.name==\"$(kubectl config current-context)\")].context.namespace}") '

I frankly don't even know if it's possible to get the current namespace from client-go

--ignore-ns setting would only be used when --ns or --current-ns aren't specified (can't see it helps any other approach?)

I was thinking it'd default to kube-system. It can be disabled by making it empty; --ns and --current-ns could have precedence over it too I guess. It helps because I don't think many people want to see the kube-system logs.

@rcoup
Copy link
Author

rcoup commented May 9, 2019

It can be disabled by making it empty; --ns and --current-ns could have precedence over it too I guess.

I think that's the logic I wrote down? If you specify ns/current-ns then you don't get "all" anymore, and anything you do specify should override the ignore list anyway.

@boz
Copy link
Owner

boz commented May 9, 2019

I think that's the logic I wrote down.

👍 pre-coffee parsing never works for me. Thanks for the input!

boz added a commit that referenced this issue May 16, 2019
boz added a commit that referenced this issue May 16, 2019
@boz boz closed this as completed in 14e2382 May 16, 2019
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

No branches or pull requests

2 participants