facilitate the use of Kustomization healthChecks on Helm-based units (and use it with Rancher)
Closes #102 (closed)
This MR:
-
does the change proposed in #102 (closed)
-
leverages it to improve how we "wait for Rancher", to compensate the fact that additionally to the resources directly installed by
rancherHelm release, therancherDeployment pods create tons of other things, on that other units actually need-
By waiting on the
Cluster.provisioning.cattle.ioCRD, we ensure thatcapi-rancher-import(which needs it) can avoid a longish period of CrashLoopBackoff. I opted to not list all CRDs, because I'm assuming that they should roughly be created at the same time. -
By waiting on the
rancher-webhookDeployment and Service we ensure that we don't get an unreliable tests (in the past we had a case of successful creation of a resource when done prior to rancher-webhook being in place, but failing if created afterwards - see #3 (closed)). -
I'm also optimistic than just waiting on more things helps having
first-rancher-loginspend less time in retries, and has less risks of reaching the maximum number of Job retries (this MR seems to have less test-kubeadm-capd failure that what we see these days on main)
-