support for custom columns

[zmalik]

Hi, first of all, thanks for this great tool!

I have been using it with different operators that we have built and sometimes these operators have additional information that might be of interest to show in the tree. But that would apply for kubernetes native objects also, e.g to show extra information in another column.

Would it make sense to add some configuration mechanism to configure kubectl tree to show these additional columns with configured values? heavily inspired by CRD additionalPrinterColumns? and also bringing its limitations where it won't support arrays or structures other than basic ones.

for example:

  additionalPrinterColumns:
  - JSONPath: .status.readyReplicas
    name: Ready
    type: string
  - JSONPath: .status.reason
    name: Reason
    type: string

assuming the customApp has .status.reason this would result in:

NAMESPACE  NAME                                      READY     REASON    AGE  READY
default    CustomApp/blueprint                       -         Updated   47h
default    ├─Deployment/blueprint                    -                   47h   1
default    │ └─ReplicaSet/blueprint-5d56cc7c4f       -                   47h
default    │   └─Pod/blueprint-5d56cc7c4f-hmbjr      True                47h
default    ├─PodDisruptionBudget/blueprint           -                   47h
default    └─Service/blueprint                       -                   47h
default      └─EndpointSlice/blueprint-wkjd2         -                   47h

and question would be where this additional config of kubectl-tree would live in 🙂

[ahmetb]

I am inclined to say no because this only came from you and I don't know the use case for this —and currently it's just you wanting this.

This tool is for understanding object hierarchy. You can then follow up in another tool like kubectl to get more info.

I think this sort of config file and custom field extraction logic would complicate the code as well as the user experience unnecessarily.

[zmalik]

thanks for the quick comment. the use-case is for operators using multiple levels of objects expansion where A creates B and B creates C and C ultimately creates kubernetes native objects. And error might happen at any level. Watching the custom status field of those in a tree hierarchy has been really helpful. Mostly like OAM based kubevela or crossplane.

but your comment makes sense. I will close the issue as I was also not so sure about the config part.