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

Events should be viewable in a separate output #254

Open
juozasg opened this issue Apr 27, 2022 · 1 comment
Open

Events should be viewable in a separate output #254

juozasg opened this issue Apr 27, 2022 · 1 comment
Labels
UI UI issue or enhancement
Milestone

Comments

@juozasg
Copy link
Collaborator

juozasg commented Apr 27, 2022

Being able to right-click an item, like a HelmRelease and quickly see events would help to debug cluster issues

@kingdonb
Copy link
Collaborator

I don't know if we need a separate right-click to activate, or if it can go right in there. Fixing #258 might also fix this if we replace the YAML view with the Describe view.

I think the hover pane is even closer to the user and might be the best change to fix this UX issue that mostly affects HelmReleases.

The HelmRelease is the priority item to deal with, because HelmRelease does not provide details of what went wrong in the status, it just says "install retries exhausted" or "upgrade retries exhausted."

So you are supposed to go check out the Events that are associated with the HelmRelease in order to see what caused the recent failure, and the only way to do this right now is to open up a terminal and run kubectl describe HelmRelease <foo>.

That doesn't mean we only make this change for HelmReleases, I think the events could be useful from any of the Flux resources, we should find a way to expose them consistently for all resources.

#258 is related to this issue but more broadly scoped "search and destroy JSON and YAML output" – anywhere we are emitting YAML or JSON, there's a solid chance we can do something more human-friendly, and in most cases this will be kubectl describe of the same resource. Making this change across the board would probably resolve it, but this is a divergence from what the Kubernetes plugin does, maybe would be a good idea to keep this behavior where it can still be accessed; I'm not sure if this change might break anyone's existing use cases?

@kingdonb kingdonb added this to the 0.26 milestone Sep 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
UI UI issue or enhancement
Projects
None yet
Development

No branches or pull requests

2 participants