Generate patches for Kustomize to enable storage versioning

[theunrepentantgeek]

What this PR does / why we need it:

Enabling versioning requires the yaml files generated by controller-gen to be modified by Kustomize to inject the required settings.

We modify the existing gen-kustomize mode of our generator to write the required files.

How does this PR make you feel:

Prerequisites:

• Merge PR Copy both ObjectMeta and TypeMeta when doing version conversion #1985

[codecov-commenter]

Codecov Report

Merging #1973 (78442d0) into main (bb8f228) will decrease coverage by 0.05%.
The diff coverage is 7.29%.

@@            Coverage Diff             @@
##             main    #1973      +/-   ##
==========================================
- Coverage   57.21%   57.16%   -0.06%     
==========================================
  Files         422      425       +3     
  Lines       85624    85709      +85     
==========================================
+ Hits        48993    48998       +5     
- Misses      30368    30448      +80     
  Partials     6263     6263              

Impacted Files	Coverage Δ
v2/tools/generator/gen_kustomize.go	0.00% <0.00%> (ø)
...or/internal/kustomization/conversion_patch_file.go	0.00% <0.00%> (ø)
...r/internal/kustomization/crd_kustomization_file.go	0.00% <0.00%> (ø)
...ator/internal/kustomization/resource_definition.go	0.00% <0.00%> (ø)
...2/internal/testcommon/kube_test_context_envtest.go	76.68% <100.00%> (+0.73%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bb8f228...78442d0. Read the comment docs.

[babbageclunk]

Looks mostly great! I think you need to build config/crd rather than config/default as it does too much (in particular name/namespace mangling), and then that has knock-on consequences for the tasks.

[babbageclunk]

Oh, I guess the benefit of putting the patched CRD output somewhere under config/crd is that we can hardcode it here rather than trying to feed it in as a parameter somehow. That makes sense.

[babbageclunk]

I've just realised - we'll also need a v2/config/crd/kustomizeconfig.yaml, which needs to be referenced from v2/config/crd/kustomization.yaml. The content of the file can just be the same as v1's config/crd/kustomizeconfig.yaml.

This tells kustomize how to find names and namespaces that need to be updated when it applies the mangling (to put azureserviceoperator- at the start). (An amusing consequence of this being missing is that in fact the config/default-built CRDs don't have mangled conversion config like I thought, but they should - they won't work in a real cluster if the mangling isn't done.)

Some documentation links about this:

• https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/
• https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs

[theunrepentantgeek]

/ok-to-test 9979cc3

[matthchr]

@theunrepentantgeek I don't think you should need to ok-to-test this PR as it's not from a fork. Is that not what you experienced?

[babbageclunk]

This looks good, but I'm not sure about copying the TypeMeta field - isn't that always determined by the package+type that it's on?

[babbageclunk]

Uh, bing?

[theunrepentantgeek]

I think I fixed this with my force push. 😊

[matthchr]

This doesn't look fixed?

[babbageclunk]

I thought you needed to avoid doing this, since it ends up copying the GVK from one version to another?

[theunrepentantgeek]

Yeah, I had changes that I hadn't pushed. Now fixed.

[babbageclunk]

/ok-to-test sha=fb727a1