add a back door to modify the schema

[shawkins]

There is a lot of complexity / trepidation with broadening and documenting our annotation support for advanced cases including structural schema. Just wanted to make a quick proposal of a way to give users lower level control over schema generation. Shown here as an object level annotation, but it would probably be applicable in other places as well.

This would be understood / documented as something for advanced usage and would require devs to add a provided scope dependency to crd-generator-api-v2.

We could offer at least 1 built-in customizer - that simply deserializes the input as the replacement. You could also entertain one that applies a patch.

The order in which the annotations are applied needs to be well defined - or if only the highest one found should be applied. This would also be defined as being applied in some predictable largely independent way of schemaswap / from.

closes: #7355

cc @matteriben @MikeEdgar

[manusa]

I'm fine with this, having some hooks to modify the schema output doesn't seem like a too bad idea and might be suitable for several scenario and use cases.

I'm curious about @andreaTP 's thoughts

[shawkins]

Finally circled back to this. Updated the draft with a test as well. Things that could still be done:

• where should this be documented
• built-in versions: patch, full replacement?
• any context that should be passed in? Parts of the resolving context are potentially interesting to this logic. Could also be handled later by adding more optional methods to the interface.

[andreaTP]

I'm curious about @andreaTP 's thoughts

Noticing the mention only now, sorry 😅 looks like a great idea to me!

Maybe, try out 2/3 real-world use cases to verify that common needs are covered.

[shawkins]

I've added the KubernetesSerialization to the customizer method, a small doc blurb, and a couple of simple built-in customizers.

Noticing the mention only now, sorry 😅 looks like a great idea to me!

Maybe, try out 2/3 real-world use cases to verify that common needs are covered.

@matteriben @MikeEdgar is there anything else that should be built-in?

[MikeEdgar]

is there anything else that should be built-in?

Nothing is jumping out to me at the moment. Having a post-processor like this should be powerful enough to cover most, if not all scenarios. I haven't tinkered with the CRD schemas for our operator in a while, so certainly something could come up that isn't obviously unsupported here. +1 from me on this feature.

[metacosm]

LGTM