CLOUDP-381747: Generate Group

[josvazg]

Summary

Make Group non experimental

• New config/generated/crd/production-kinds.json is an array promoting generated CRDs to production.
• Atlas Generated Group documentation appears, filling properly from comments is WIP.
• Registry has now separated legacyReconcilers and generatedReconcilers functions.
• Similarly Indexers are also setup separately as legacyIndexers and generatedIndexers.
• The whole generatedv1 scheme is always loaded. These means that some unusable experimental schemes use some memory in production, but will not be exposed.
• Generated crds are split into crds.experimental.yaml and individual YAML files under config/crd/bases.

This this setup, we can continue to write experimental generated resources and chose when to promote them to production at will.

Proof of Work

TBD

Checklist

• Have you linked a jira ticket and/or is the ticket in the title?
• Have you checked whether your jira ticket required DOCSP changes?
• Have you signed our CLA?

[s-urbaniak]

why is this special treatment needed?

[josvazg]

The idea is that we produce generated resources once, as done today, but them pick which ones are promoted as production ready.

I am open to alternatives, but one thing I would like to keep is that we should be able to work on experimental resources without releasing them until ready. Smaller PRs, and protecting production from ongoing work are important.

[josvazg]

An alternative is we use a separate source for generated production CRDs, which would implying moving from experimental to production means cut the CRD schema from the experimental file and pasting into the production one. Not sure we want to go that path.

Another option is the other way around, mark experimental ones instead of production ready. But that is kind of dangerous, as we might expose experimental code by accident.

[s-urbaniak]

I am not convinced we need experimental support any more and introduce more complexity. we know we want to promote these CRDs now, why do we want to add additional complexity, I don't see a requirement from the PD+Scope/TD for this.

[josvazg]

We are going for solving the experimental/non experimental split in the openapi2crd config, by using different domains in the group version. Experimental will be optional, not a pre-step before promoting as prod.