Make sure CRDs are in sync with their counterpart Go structs

[kensipe]

What would you like to be added:

We need a test that confirms that the structs used for CRDs are compatible with CRDs. We need to gen out crds and do a round trip check to confirm changes in code are consistent with CRDs.

Why is this needed:

[alenkacz]

I believe this will also be solved with proper e2e tests for some basic scenarios.

[gerred]

Looks like kubebuilder is using controller-gen: https://github.com/kubernetes-sigs/controller-tools. https://github.com/kubernetes-sigs/controller-tools/blob/master/pkg/crd/doc.go

[porridge]

A little overdue update on my approach:

Currently we need to use our brains to always make sure that the CRDs - for example the OperatorVersion spec needs to match the Go struct fields - otherwise we will either lose data or face serialization/deserialization errors. There is currently no test which ensures that these definitions are in sync, and (surprise!) they were NOT in sync until very recently - luckily so far just in case of (mostly) unused fields that do not matter that much, or with regard to the human readable descriptions. The bulk of the long slew of PRs referenced above this comment where I made sure they are back in sync.

Now, my plan going forward is not to introduce tests that try to detect whether these are in sync by round-tripping data back and forth, because that is going to be tedious and error-prone, and be just as susceptible to bit-rot (i.e. we'd need to remember to test new fields as we add them) as the current situation.

My plan instead is to make the structs in the apis package into the single source of truth, i.e. have the CRDs YAML generated from them using controller-gen, and then have the resulting YAML embedded into the kudoinit package with go-bindata, getting rid of that duplicate definition.

In order to optimize for review speed and quality I'm doing this in small chunks each of which is obvious and quick to review. Because if I did it all in one go, there would be a 300-500 line YAML diff, which would be impossible to make sure is correct.

So I'm kind of trying to avoid the need for round-trip testing in the first place (will update the summary in a moment).
We'll effectively replace this with trusting controller-gen, but I think it's a good trade-off.

[alenkacz]

sounds good 👍