Custom additionalPrinterColumns for created CRDs #478

petar-cvit · 2025-04-03T09:17:41Z

closes #476

Description

Adds additionalPrinterColumns to RGD and maps the columns to the created CRD in the RGD reconciler.

cc: @a-hilaly

Signed-off-by: petar-cvit <[email protected]>

a-hilaly

Thank you for your PR @petar-cvit ! The PR implementation for custom additionalPrinterColumns looks correct overall.

However i wanted to explore an alternative approach with you, what if we enhanced the SimpleSchema instead of introducing a new top level field? users could potentially do something like:

schema:
  spec:
    name: string | required=true print=true # or kubectl_print=true

I recognize this wouldn't be sufficient for complex printer columns with additional attributes.

I also just came across KEP 4602 (https://github.com/kubernetes/enhancements/pull/4602/files) which seems relevant. We might want to explore this direction in parallel as it could influence our approach here.

Would love to hear your thoughts here :)

petar-cvit · 2025-04-06T09:56:22Z

Hey @a-hilaly, thanks for the alternative approach! If we want to add the printer columns to the simple schema, we can easily get the JSONPath for a specific field. Also, this seems easier for users to set up.

I was also thinking about whether additionalPrinterColumns should be top-level with schema and resources, but it seems like we are losing a lot of flexibility for users in the long run if those are defined in the simple schema, especially with the CEL enhancement proposal.

In the case of CEL columns (as described in the KEP), tieing a CEL expression to a field using simple schema doesn't seem like the right fit, primarily because CEL expressions work with the whole CRs and can get data from multiple fields at once (KEP example expression: self.status.replicas == self.spec.replicas ? "READY" : "WAITING").

My point is that if we want to design it with CEL columns in mind, simple schema is probably not the way to go, but not sure how much should a KEP influence design decisions.

One argument for having a dedicated additionalPrinterColumns is that it follows how those are configured for CRDs, and users are familiar on how to use them.

Let me know what you think about the points I mentioned. Happy to discuss further

a-hilaly · 2025-04-08T09:31:33Z

Yeah, I totally agree with everything you said @petar-cvit . Keeping additionalPrinterColumns separate makes a lot of sense, especially when thinking about where the KEP is heading. Maybe supporting the simple schema another day could provide a faster way to inject additionalPrinterColumns, just as a way to expose data directly into the kubectl output. with that said i think we should go with this PR :)

a-hilaly · 2025-04-08T09:34:28Z

@petar-cvit BTW there's an ongoing thread in our Slack about introducing simple schema custom types and whether they should live directly in spec or in spec.schema. Regardless of where we land on that one, I think additionalPrinterColumns and these type definitions should probably live under the same parent field for consistency. Mind dropping your thoughts in that thread if you get a chance?

a-hilaly · 2025-04-08T09:37:19Z

pkg/graph/crd/crd.go

+func newCRDAdditionalPrinterColumns(additionalPrinterColumns []extv1.CustomResourceColumnDefinition) []extv1.CustomResourceColumnDefinition {
+	if len(additionalPrinterColumns) == 0 {
+		return defaultAdditionalPrinterColumns
+	}
+
+	return additionalPrinterColumns
+}


Thought: what are your thoughts on injecting specific default CustomResourceColumnDefinition objects, when they aren't specfied by users? that way we ensure that STATE/SYNCED/AGE are always included?

My reasoning was that users might not need the default columns and might want to remove them. If they are already customizing printer columns, my guess is that they want to show a specific state of their CRs.

However, I don't have such a strong opinion on this, and I can merge the defined additionalPrinterColumns with the default ones based on the name. Let me know if you agree with the point above or if we should add the default columns, and I can add them.

I think allowing users to override our default printer columns seems reasonable. If they want to maintain the existing ones, they should be able to.

I mentioned above we should call that out in the docs though

petar-cvit · 2025-04-08T15:49:54Z

Thanks for the link to the discussion @a-hilaly. I left a comment with a different approach in the thread that might allow you to reuse types in multiple RGDs. Let me know if it makes sense or if it's overkill for this problem

a-hilaly

Neat, thanks @petar-cvit !

matthchr · 2025-04-16T23:49:08Z

api/v1alpha1/types.go

@@ -43,6 +44,11 @@ type ResourceGraphDefinitionSpec struct {
 	//
 	// +kubebuilder:validation:Optional
 	DefaultServiceAccounts map[string]string `json:"defaultServiceAccounts,omitempty"`
+	// AdditionalPrinterColumns defines additional printer columns that will


Worth calling out that setting this overrides the default printer columns, and if the user wants to retain the default columns they will need to specify them here explicitly?

@matthchr, I just added the comment you proposed. Let me know if there is anything else

matthchr · 2025-04-16T23:50:27Z

pkg/graph/crd/crd.go

+func newCRDAdditionalPrinterColumns(additionalPrinterColumns []extv1.CustomResourceColumnDefinition) []extv1.CustomResourceColumnDefinition {
+	if len(additionalPrinterColumns) == 0 {
+		return defaultAdditionalPrinterColumns
+	}
+
+	return additionalPrinterColumns
+}


I think allowing users to override our default printer columns seems reasonable. If they want to maintain the existing ones, they should be able to.

I mentioned above we should call that out in the docs though

Signed-off-by: petar-cvit <[email protected]>

matthchr

LGTM, but need to regenerate CRD yaml I think

config/crd/bases/kro.run_resourcegraphdefinitions.yaml

Signed-off-by: petar-cvit <[email protected]>

matthchr · 2025-05-08T22:39:20Z

Spoke with @a-hilaly and he pointed out this might make more sense on schema rather than at the top level like you have it. I agree, temporarily dropping my approval as I think we should push this to schema

matthchr

Move to schema (as mentioned in other comment)

joshuabaird · 2025-05-08T23:56:05Z

Thanks for this @petar-cvit -- very useful feature! I wonder if we could/should document additionalPrinterColumns somewhere? If not in the official docs, maybe an example in the example/ directory?

Signed-off-by: petar-cvit <[email protected]>

petar-cvit · 2025-05-10T19:01:58Z

Moved additionalPrinterColumns down to schema.

If not in the official docs, maybe an example in the example/ directory?

@joshuabaird, thanks for the feedback! I saw you opened an issue about the docs - #543. I'd be happy to add an example of this to the repo, but if there will be a generic solution for the docs, maybe we can leave it out for now. @a-hilaly, what do you think?

a-hilaly

Thank you very much @petar-cvit ! 👍

a-hilaly · 2025-05-12T10:40:40Z

I think this should ideally be documented in https://kro.run/docs/concepts/simple-schema - so far we don't have any automation to generate that page. Happy to take a seperate PR for it :) @petar-cvit would like to take a stab a this? or maybe add an example in /examples directory?

petar-cvit · 2025-05-12T12:19:04Z

Added examples of additionalPrinterColumns to /examples and to the website as well in a separate PR #547

cc @a-hilaly

* add additionalPrinterColumns to RGD CRD * map additionalPrinterColumns when creating CRDs * add mapping tests * add additionalPrinterColumns comment * gen ResourceGraphDefinition crd * move additionalPrinterColumns under schema * rename import

petar-cvit added 3 commits April 3, 2025 11:01

add additionalPrinterColumns to RGD CRD

3644816

Signed-off-by: petar-cvit <[email protected]>

map additionalPrinterColumns when creating CRDs

073d1d7

Signed-off-by: petar-cvit <[email protected]>

add mapping tests

78abb15

Signed-off-by: petar-cvit <[email protected]>

a-hilaly reviewed Apr 6, 2025

View reviewed changes

a-hilaly reviewed Apr 8, 2025

View reviewed changes

a-hilaly previously approved these changes Apr 16, 2025

View reviewed changes

matthchr previously approved these changes Apr 16, 2025

View reviewed changes

add additionalPrinterColumns comment

ab6fd3c

Signed-off-by: petar-cvit <[email protected]>

petar-cvit dismissed stale reviews from matthchr and a-hilaly via ab6fd3c April 23, 2025 08:11

petar-cvit requested a review from matthchr April 23, 2025 08:13

matthchr previously approved these changes Apr 23, 2025

View reviewed changes

config/crd/bases/kro.run_resourcegraphdefinitions.yaml Outdated Show resolved Hide resolved

gen ResourceGraphDefinition crd

76e4fea

Signed-off-by: petar-cvit <[email protected]>

petar-cvit dismissed matthchr’s stale review via 76e4fea April 23, 2025 16:41

petar-cvit requested review from matthchr and a-hilaly April 23, 2025 17:11

Merge branch 'main' into feat/custom-additional-printer-columns

be81065

matthchr previously approved these changes May 8, 2025

View reviewed changes

matthchr reviewed May 8, 2025

View reviewed changes

move additionalPrinterColumns under schema

9ec0293

Signed-off-by: petar-cvit <[email protected]>

petar-cvit dismissed matthchr’s stale review via 9ec0293 May 10, 2025 18:31

rename import

ca1bf51

Signed-off-by: petar-cvit <[email protected]>

a-hilaly approved these changes May 12, 2025

View reviewed changes

petar-cvit mentioned this pull request May 12, 2025

Add additionalPrinterColumns examples to docs #547

Merged

barney-s merged commit 5cfb132 into kro-run:main May 12, 2025
4 checks passed

Custom additionalPrinterColumns for created CRDs #478

Custom additionalPrinterColumns for created CRDs #478

Uh oh!

Conversation

petar-cvit commented Apr 3, 2025

Description

Uh oh!

a-hilaly left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petar-cvit commented Apr 6, 2025

Uh oh!

a-hilaly commented Apr 8, 2025

Uh oh!

a-hilaly commented Apr 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

a-hilaly Apr 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petar-cvit Apr 8, 2025

Choose a reason for hiding this comment

Uh oh!

matthchr Apr 16, 2025

Choose a reason for hiding this comment

Uh oh!

petar-cvit commented Apr 8, 2025

Uh oh!

a-hilaly left a comment

Choose a reason for hiding this comment

Uh oh!

matthchr Apr 16, 2025

Choose a reason for hiding this comment

Uh oh!

petar-cvit Apr 23, 2025

Choose a reason for hiding this comment

Uh oh!

matthchr Apr 16, 2025

Choose a reason for hiding this comment

Uh oh!

matthchr left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

matthchr commented May 8, 2025

Uh oh!

matthchr left a comment

Choose a reason for hiding this comment

Uh oh!

joshuabaird commented May 8, 2025

Uh oh!

petar-cvit commented May 10, 2025

Uh oh!

a-hilaly left a comment

Choose a reason for hiding this comment

Uh oh!

a-hilaly commented May 12, 2025

Uh oh!

petar-cvit commented May 12, 2025

Uh oh!

Uh oh!

Uh oh!

a-hilaly left a comment •

edited

Loading

a-hilaly commented Apr 8, 2025 •

edited

Loading

a-hilaly Apr 8, 2025 •

edited

Loading