sylva-units: introduce versioned-dependency Kustomizations

General Context

Let's consider the case where:

• Kustomization A depends on Kustomization B
• we do an update sylva-units that involves changing what A produces
• we would like B to not be updated before A is updated and "ready"

This is something that our system does not ensure today, because this is not something that FluxCD Kustomization dependsOn can ensure.

The reason is that, assuming that:

kind: Kustomization
metadata:
  name: a
spec:
  dependsOn:
    name: b

Then on an update of sylva-units, Kustomizations A and B are updated by Helm but:

• their update is certainly not atomic
• we don't control or know in which order Helm will apply them
• even if we would control that, we can't control in which order the FluxCD Kustomization controller will reconciliate them
• (even if we would control that, we couldn't prevent a reconciliation for B to happen before A is updated)

As a result of that, a reconciliation of Kustomization B may occur before a reconciliation of A for the new release has occurred.

As a consequence, it is very possible that B is updated before A is updated and "ready".

Specific instances of this problem

• the case that lead me to solve this problem: cluster-machines-ready was introduced as a "checkpoint" to ensure that units depending on the cluster unit don't merge before the CAPI rolling update is done (see !2032 (merged) and !2054 (merged)) -- but unless the issue described here is addressed, we run into cases where those units reconcile immediately when syvla-units is updated
• we have the same potential issue for cluster-ready, but this is the same topic as the one above because the "cluster-ready-unit", today is the only unit one depending on cluster-ready
• os-images-info: we ran into this issue in the past for os-images-info, we had the get-openstack-images reconcile too early on a sylva-units update that changed sylva_diskimage_builder information, before os-images-info would have run -- this was solved by having get-openstack-images read a configmap with a dynamic name (hence failing/retrying until the fresh ones would appear)

Solution

This MR introduces a solution to this issue by making the name of Kustomization B dynamic, suffixed by the Helm revision.

kind: Kustomization
metadata:
  name: b-5
spec:
  ...

kind: Kustomization
metadata:
  name: a
spec:
  dependsOn:
    name: b-5

On an update, Kustomization a is updated with a new reference to the Kustomization for unit a that includes the new revision, and hence will not reconcile before this new Kustomization b-5 is ready.

What this MR does

This MR:

• implements the solution described above with a "unit template" called versioned-dependency that can be used on any unit that other units need to depend on in a "versioned" way
• applies it to a few units on which this is relevant, in particular cluster-machines-ready

This MR does not refactor the os-images-info unit to benefit from versioned-dependency - this will be covered in a follow-up MR.

References

• this MR is a follow up to !2032 (merged), !2054 (merged) which are meant to partially mitigate #1157 (closed)