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
{{ message }}
This repository has been archived by the owner on Jul 30, 2023. It is now read-only.
While I believe kubecolor colorizes the kubectl output nicely, I don't think current implementation is best. The better color schema might be found in the future.
Now, there are a lot of color schema change requests:
It will be possible to implement all the things, but I'm concerned the kubecolor will be not very simple and not easy to use. In the first place, this kind of thing is completely personal preference.
In my opinion, we have to options:
Keep it simple. No color customization ability in kubecolor. If you don't like it's color schema, you can fork and change it.
I don't want to make kubecolor too complicated, I want to keep it simple as much as possible. However, the really useful feature should be builtin without configuration file.
I want to gather the opinion.
The text was updated successfully, but these errors were encountered:
Maybe we could start by the 'why' we (would) use this promising tool. For now I don't.
My 'why' : highlight resources problems with colors.
And I believe it is the case for more than half the issues gathered.
So for me, the minimum would be to differentiate bad/transitioning/good state of each field, whatever the color, but preferably conventional (red/yellow/green).
Most important: Would be useful to have colored indication of a resource state: STATUS, READY and RESTARTS to see problems easily.
Other than that might be useful to specify custom color by their NAMESPACE and NAME using e.g. a pattern.
So e.g. different color for services, logging, monitoring, DB ...
While I believe kubecolor colorizes the kubectl output nicely, I don't think current implementation is best. The better color schema might be found in the future.
Now, there are a lot of color schema change requests:
#110
#102
#91
#89
#88
#77
#76
It will be possible to implement all the things, but I'm concerned the kubecolor will be not very simple and not easy to use. In the first place, this kind of thing is completely personal preference.
In my opinion, we have to options:
Two things on the second option:
I don't want to make kubecolor too complicated, I want to keep it simple as much as possible. However, the really useful feature should be builtin without configuration file.
I want to gather the opinion.
The text was updated successfully, but these errors were encountered: