Use appropriate CRD API during readiness check

[zubron]

Please add a summary of your change

The readiness check for the Velero CRDs was still using the v1beta1 API.
This would cause the readiness check to fail on 1.22 clusters as the
v1beta1 API is no longer available. Previously, this error would be
ignored and the installation would proceed, however with #4002, we are
no longer ignoring errors from this check.

This change modifies the CRD readiness check to check the CRDs using the
same API version that was used when submitting the CRDs to the cluster.
It also introduces a new CRD builder using the V1 API for testing.

This change also fixes a bug that was identified in the polling code
where if the CRDs were not ready on the first polling iteration, they
would be added again to the list of CRDs to check resulting in
duplicates. This would cause the length check to fail on all subsequent
polls and the timeout would always be reached.

Signed-off-by: Bridget McErlean bmcerlean@vmware.com

Please indicate you've done the following:

• Accepted the DCO. Commits without the DCO will delay acceptance.
• Created a changelog file or added /kind changelog-not-required.
• Updated the corresponding documentation in site/content/docs/main.

[sseago]

Just a minor comment on something in code comments before a func. Not a merge blocker, but the update would make things a bit clearer.

[sseago]

The restore code which uses IsUnstructuredCRDReady doesn't really need to deal with v1/v1beta1 issues right now. I'm guessing that by the time this code is refectored (if it is ever refactored) we'll no longer be supporting v1beta1, so the above (and below) lines should probably reference IsV1CRDReady instead.

[zubron]

Ah, that was a find/replace gone wrong :) I'll fix it.

[zubron]

I checked yesterday, and the upstream fix is available in the v0.20.0 version of the API libraries. Once we upgrade those, a unit test which checks for the upstream error will fail which might encourage the refactoring at that stage.

[sseago]

Ahh. OK. If we choose to do that soon we'll need to deal with v1 vs v1beta1 issues in the refactor.

[zubron]

I've updated the comment, but I think there is quite a bit of history surrounding this issue which I'm not fully aware of. Let me know what you think and I can change it again if you think it could be clearer.

[sseago]

I think that's fine. The issue was that the typed checks were failing with CRDs which included int64 fields. Velero CRDs don't use those, so the installer wasn't hitting the problem, but restoring backups which included CRDs with these fields was failing. The workaround was to use the unstructured fields. I don't know whether it really matters enough at this point to go back and refactor the restore CRD ready checks to use the v1/v1beta1 functions, but if we do we just need to make sure that the int64 issue is gone by testing backup/restore with a CRD which uses this sort of field.