CRDGenerator: Allow to configure conversion webhooks

[baloo42]

Is your enhancement related to a problem? Please describe

At the moment there is no easy way to configure conversion webhooks for the generated CRDs:

https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#configure-customresourcedefinition-to-use-conversion-webhooks

Describe the solution you'd like

A solution could be to create one or more additional annotations which allows a user to configure the webhook.

Describe alternatives you've considered

No response

Additional context

See also: https://github.com/fabric8io/kubernetes-client/issues/4692

[baloo42]

PoC: https://github.com/baloo42/kubernetes-client/pull/3

[andreaTP]

You might want to checkout this repo too: https://github.com/operator-framework/josdk-webhooks

cc. @csviri

[baloo42]

I already used JOSDK-webhooks as well as JOSDK, QOSDK and of course fabric8/kubernetes-client in a few real world projects. And I love it ;) My last project for example was developing a Keycloak Entity Operator.

There are only some small things missing which I would like to contribute in the near future. To name a few planned improvements:

• Support for the whole lifecycle of an Java Operator using the code-first approach and without the need of further kustomizing the generated CRDs. (Multi-Version CRDs, ConversionWebhooks, Version Deprecation, Deterministic Output)
• Better support for the code-first approach / CRDGenerator:
  • Kubernetes Validations / CEL
  • Size constraints
  • List Type (x-kubernetes-list-type)
  • Map Type (x-kubernetes-map-type)
  • ListMapKeys (x-kubernetes-list-map-keys)
  • Embedded Resources (x-kubernetes-embedded-resource)
  • External Docs
  • ...
• JOSDK: Better support for dynamic read-only dependant resources
• JOSDK: Better support for events and status aggregators
• Support for generating documentation websites for operators (CRDs, Metrics, Events, Status...)
• Better support for Spring-Boot based operators

[csviri]

Hi @baloo42

JOSDK: Better support for dynamic read-only dependant resources JOSDK: Better support for events and status aggregators

feel free to create issues for those and pls describe the enhancement for the current approach. Note that currently we are working on v5, so we can make some breaking changes.

Better support for Spring-Boot based operators

That would be more than welcome, unfortunately, we have limited time, basically spring boot starter is now in maintenance mode.

[andreaTP]

I already used JOSDK-webhooks as well as JOSDK, QOSDK and of course fabric8/kubernetes-client in a few real world projects. And I love it ;)

Nice! 🎉 And many thanks for engaging with us and contributing back, much appreciated!

My last project for example was developing a Keycloak Entity Operator.

Is it Open Source? If not, would you share details of its design? I'm interested and probably also @shawkins

Kubernetes Validations / CEL

FYI this exists: https://github.com/projectnessie/cel-java I would love to see something happening in the area!

the code-first approach

This is completely out of curiosity for me, any specific reason why you prefer code first as opposed to contract first?

[baloo42]

feel free to create issues for those and pls describe the enhancement for the current approach. Note that currently we are working on v5, so we can make some breaking changes.

I will do before I start, thanks for the hint. We don't need those changes in the near future, so it makes sense to me contribute directly to v5. In short: We have produced a lot of NPEs in the past because status, status conditions and events must be passed through sometimes. I'm looking for a base implementation to avoid those often made mistakes.

That would be more than welcome, unfortunately, we have limited time, basically spring boot starter is now in maintenance mode.

We noticed that too. We started with the starter but had to switch to our own base. Maybe I can help here to add some missing features, make it easier to maintain and if you wish i can also help you with maintenance. Started a discussion in https://github.com/operator-framework/josdk-spring-boot-starter/issues/142

Is it Open Source? If not, would you share details of its design? I'm interested and probably also @shawkins

Unfortunatly it's not open source. But my customer has an Open Source program and they might discuss this in the future. Until that, we can discuss some general design decisions. Can you suggest a place for it? We had to implement a lot of workarounds for Keycloak's Admin REST API e.g. for Authentication Flows or Permissions for Token-Exchanges, which made me think of improving those pain points first and directly in Keycloak itself.

Kubernetes Validations / CEL FYI this exists: https://github.com/projectnessie/cel-java I would love to see something happening in the area!

Let's discuss it! --> https://github.com/fabric8io/kubernetes-client/discussions/5851

This is completely out of curiosity for me, any specific reason why you prefer code first as opposed to contract first?

Good question :smiley: It's often not my decision alone and I used both approaches in the past. I also think it heavily depends on the team and on the use case. But if I have the choice and if it fits to the use case, I prefer the code-first strategy. I think the main reason behind of this decision is, that I hope to onboard other developers faster. My team members have made often good experiences by using the Code-First stategy on REST APIs (springdoc, smallrye, CXF OpenAPI Feature). On the other side I have often seen broken Contract-First approaches, because at some time they gave up generating code and worked on by directly manipulating the code.

[andreaTP]

Can you suggest a place for it? We had to implement a lot of workarounds for Keycloak's Admin REST API e.g. for Authentication Flows or Permissions for Token-Exchanges, which made me think of improving those pain points first and directly in Keycloak itself.

Probably, the best place to have this discussion in public is here: https://github.com/keycloak/keycloak/discussions If you feel uncomfortable having this discussion in the open, my personal email address is public on my GH profile, feel free to drop me an email 🙂

And thanks for the feedback on the rest of the subjects!

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[BramMeerten]

You might want to checkout this repo too: https://github.com/operator-framework/josdk-webhooks

I'm using the JOSDK framework as well, and it's useful for creating the conversion webhooks. But they still need to be configured in the CRD. For the creation of CRD I use crd-generator, they are programmatically generated and deployed.

So I'm also intereseted in this proposal, because currently I can't configure the webhook for the CRD.