-
Notifications
You must be signed in to change notification settings - Fork 483
Custom Resource view doesn't align with kubectl #405
Comments
@alanmeadows thanks for reporting this, this appears to be a bug. If a CRD defines AdditionalPrinterColumns they should be rendering in our table view. https://github.com/vmware-tanzu/octant/blob/master/internal/printer/customresource.go#L33 is the code in question. |
@wwitzel3 Thanks! Appreciate pointing out the code location. My brief take would be that per https://github.com/kubernetes/apiextensions-apiserver/blob/master/pkg/apis/apiextensions/types.go#L34 that while it supports "global" AdditionalPrinterColumns ( I think https://github.com/kubernetes/apiextensions-apiserver/blob/master/pkg/apis/apiextensions/types.go#L192-L200 helps me understand what is going on at least. |
@alanmeadows yep, that looks like the case to me as well, if you're up for it, and created a PR I'd be happy to review it and help get it merged in. |
@GarySmith want to take a look at a PR for this? |
@alanmeadows Sure, I can do that |
It looks like it is more complicated than just not rendering version specific columns. Even global printer columns do not work. For example, load (with Digging a little deeper, it appears that in the running product the CRD that is passed to the CustomResourceListHandler in customeresource.go is structured differently than is expected -- the (In the unit test, the CRD is formatted "correctly", with the |
Thank you for looking at this @GarySmith . I followed the steps you mentioned, of using the testdata CRD and it indeed does not render the output table correctly and the tests do seem to suggest the renders are working. I'm going to dig a bit deeper in to this, I'll report back what I find. |
Custom Resource Definitions may additionalPrinterColumns that are specific to a give api version. The CustomResourceHandler and CustomResourceListHandler were only handling top-level additionalPrinterColumns that apply to all columns regardless of version. This change handles version-specific additionalPrinterColumns. This change addresses vmware-archive#405
Custom Resource Definitions may additionalPrinterColumns that are specific to a give api version. The CustomResourceHandler and CustomResourceListHandler were only handling top-level additionalPrinterColumns that apply to all columns regardless of version. This change handles version-specific additionalPrinterColumns. This change addresses vmware-archive#405 Signed-off-by: Gary Smith <garysmith123@gmail.com>
The view octant provides for custom resources is limited in usefulness as it does not take advantage of the rich column data that kubectl can display defined within the CRD. My expectation is that there would be parity between these two views in terms of a listing of objects.
For instance:
vs:
This would be expected to have been provided by the CRD as printer columns, such as the case for the
baremetalhosts.metal3.io
below -- perhaps defaulting back to the view that is currently available on Octant when these are not defined in a CRD. However, in this case, the CRD owner has informed us of what is important in terms of columns already.The text was updated successfully, but these errors were encountered: