Consider Java generation from CRD

Is your enhancement related to a problem? Please describe

In K8s Custom Resource Definitions are a contract defined by the developers.

There are two different approaches to “generation”:

• code first
• contract first

---

Definition:

code first: you add, along with the code, informations (e.g. usually annotations in Java world) about the desired final result for your contract and you re-generate it from time to time. This is the approach taken in the crd-generator currently in preview.

contract first: you write the contract and generate all the models and boilerplate code from there (for simplicity, here, we don’t make assumptions over the fact that the resulting code will be committed to VCS system or not). This is one of the features of the “official” kubernetes-client.

---

Some (biased) pros and cons:

code first: PROS:

• fast prototyping
• single language used everywhere
• quick changes
• best for the server side
• best for small teams

CONS:

• easy to accidentally break compatibility/semver
• integration with “host” language becomes an embedded DSL
• hard interoperability with other languages

contract first: PROS:

• agnostic definition
• single source of truth can be used from different languages/generators
• hard to accidentally break compatibility/semver
• best for generating clients
• best for big teams / cross-teams

CONS:

• need to write the contract first in (possibly) a different language
• more involved workflow for compiling the “host” language
• cumbersome in case of quick and breaking changes

---

Current status:

code first:

• In preview

contract first:

• couldn’t find any reference

Describe the solution you’d like

Here I’m proposing to consider adding the necessary machinery for contract first development of CRDs to this project. The key advantages/use-cases I see are:

• language agnostic definition of CRDs enables easy switching language for Operators development
• dead simple generation of clients (e.g. kubectl plugins, other operators etc.) from agnostic contracts

I started to look into the problem and this is a super early stage prototype: https://github.com/andreaTP/crd2j

What is included:

• generation of Java CR classes from CRDs
• generation of “fabric8 aware” POJOs for the OpenAPI v3 schema
• handling of arbitrary nesting of objects
• the generated code compiles for large CRDs unmodified from upstream Strimzi, Spark, Keycloak, Crunchy and more
• very basic unit tests, basic approval(aka golden) tests for the generated code and tests to guarantee that the generated code will compile

What is missing:

• real-world usage
• more names mangling/sanitizations
• a shippable format (in the form of a CLI and a Maven plugin) that can be easily integrated in a workflow
• proper handling of all edge cases not already faced in the example CRDs
• optional mapping of Objects to already defined Fabric8 Java Classes
• utilities and helpers (e.g. adding automatic generation of “builder-patters” etc.)
• … (more)

Out of scope:

• full specification coverage / I think this tool can go a long way concentrating on real-world examples other than trying to cover the humongous entire openAPI v3 spec and all of the kubernetes specific additions on top.

If there is any interest I would be more than happy to collaborate in the development of such extension to this, already outstanding, project 🙂 .

Describe alternatives you’ve considered

Using a “generic” OpenAPI v3 generator doesn’t really fit the purpose since there are “Kubernetes related” concepts that will be really hard to fit into, for example the x-kubernetes-int-or-string or x-kubernetes-preserve-unknown-fields encodings.

Additional context

No response

[fabiobrz]

Hi @andreaTP - I’ve been trying your PoC out and well… it just worked perfectly for replacing an existing legacy infinispan model which had been implemented previously in the context of an internal automation project.

Basically we are using fabric8 k8s client already and this PoC really fitted in perfectly with what we needed (legacy POJOs were implementing CustomResource, as well and existing builders now work seamlessly with no change after the model was replaced).

Regarding the discussion with @manusa about the contribution to the fabric8 k8s client, IMHO it would add big value to it, by covering all those cases which would drastically benefit from a contract-first approach - i.e. Java based cloud testing automation just to mention one 🙂 - and allowing for more robust model based components to be developed and easily maintained.

[rohanKanojia]

This is something which has been requested in past (https://github.com/fabric8io/kubernetes-client/issues/3168) . I like this idea and I’m in support of adding this to the client. However, we need to check with senior members @manusa @iocanel @metacosm @shawkins on what they think about this.