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
It would be helpful to output additional information about the disk that is not available via the kubernetes metadata properties. I am specifically looking to see the disk type(SSD vs regular) and size.
These fields will likely grow over time, so it may be useful to have a similar functionality as extraColumns. The only issue with extra columns is it appears to be coupled to kubernetes metadata.
I have an initial implementation in #44 and would be more then happy to share the results.
The text was updated successfully, but these errors were encountered:
I think I'd leave -add-column for picking stuff from the disks metadata, and instead add new boolean flags (defaulting to true or false depending on how useful they are to have all the time, and always true when -v (verbose) is used) for the these, something like:
I like it in theory, I just get a bit concerned about how it impacts the readability of the code. I'd need to see what that looks like implementation wise.
How would you feel about separating the flags to separate issue so?
It would be helpful to output additional information about the disk that is not available via the kubernetes metadata properties. I am specifically looking to see the disk type(SSD vs regular) and size.
These fields will likely grow over time, so it may be useful to have a similar functionality as
extraColumns
. The only issue with extra columns is it appears to be coupled to kubernetes metadata.I have an initial implementation in #44 and would be more then happy to share the results.
The text was updated successfully, but these errors were encountered: