Restore ordering of CR and corresponding CRD

[johannesfrey]

Hi folks, there is a case of restoring a CRD together with a corresponding CR I am wondering about:

During restore of a CR and a CRD at the same time, the CR is tried to be restored prior but it is skipped because the corresponding CRD has not yet been restored. Log line: Skipping restore of resource because it cannot be resolved via discovery.
This makes sense, as the discovery helper is listing all (current) APIs of which the CRD API is not yet present.
So the restore is finished, the CRD is then restored but the corresponding CR is not.

Just wanted to be sure if this behaviour is intended and if the user performing the restore should perform a second restore in order to also restore the backed up CRs?

Thanks in advance.

[jenting]

There is an issue with this already #3844 and we have a PR for this on the flight.

[johannesfrey]

Cool. Thank you!

[sseago]

In addition to the above (and yes, the PR for #3844 should resolve this -- I need to get some tests written to accompany the PR so that we will detect similar CR restore regressions in the future), I just wanted to provide some context for what happened. We didn't attempt to restore the CR first -- CRD is actually first on the priority list for restore. What happened was that when we implemented restore progress reporting, there was a change in logic that pre-processed all of the resources for restore so that we could count how many we're dealing with (so we could update the restore status with things like "14 items restored out of 1500"). Unfortunately, this change meant that when we got to the validation logic for the CR, while we had validated (and counted) CRDs for restore, we hadn't actually restored them yet, so the CR failed validation. The fix is to run a first restore pass that actually restores CRDs only, and then pre-process everything else for restore, getting numbers for progress reporting, etc.