OpenAPI: Investigate kubernetes model code generation

[manusa]

Description

Investigate possible improvements to the way we generate code today.

For example, a combination of Go type-inference plus OpenAPI processing would allow to include JavaDoc to the current types.
Further exploration might also allow to use OpenAPI exclusively to improve generation performance.

[manusa]

Status update

Kubernetes types

Generation from OpenAPI/Swagger JSON works and generates almost identical models for all of the Kubernetes types.

OpenShift types

Generation works, however models differ especially in class names.

The JSON produced by the OpenShift cluster contains mostly inlined schema definitions (as opposed to the Kubernetes one which has Component schema definitions for every class).
The generator PoC uses a customized InlineModelResolver that concatenates the parent field class with the field name, this means that several layers down we can get classes named such as ControlPlaneMachineSetSpecTemplateMachinesV1beta1MachineOpenshiftIoSpecMetadataOwnerReferences.

This poses 2 main problems:

• Common API machinery Kubernetes classes are not referenced from the OpenShift ones (since they are inlined) -> duplication
• Builder from the root classes be compatible with the legacy ones, since fields are initialized using withNewXxx, so this is not a problem.
  However, if the fluent builder API is not used from the root element, and approach such as . withXxx(new XxxBuilder()./*...*/.build()) is used, then this is not compatible with the previous models.

Blocker

kube-schema.json / validation-schema.json files can be used downstream to verify YAMLs and JSONs provided by users, we need to find a way to generate those with the current approach

• [schema] change in JSON schema structure for validation purpose kubernetes-model#229
• Feat/66 resource validation fabric8-maven-plugin#1029
• validate generated resources fabric8-maven-plugin#66

Opinion

Even if there are going to be some breakages for users, this will be released in a major version.
If well documented, this shouldn't be that big of a problem

Generation using this approach is extremely easy and has a very low maintenance cost.

I'd seriously consider for the migration to the new approach.

[manusa]

After internal discussion, it seems clear that we should go forward with this initiative.
I'm working #6130 to reflect all of the required stories and tasks.
This issue can be closed now.