revisit cluster_public_endpoint sylva-units value

Today, we have:

  • libvirt-metal producing cluster-public-endpoint ConfigMap
  • cluster-public-endpoint ConfigMap set as input to sylva-units HelmRelease, to position the cluster_public_endpoint value
  • ... but nothing in sylva-units seems to actually use cluster_public_endpoint
  • this cluster_public_endpoint seems to only be used by retrieve_kubeconfig (in https://gitlab.com/sylva-projects/sylva-core/-/blob/2ccacfd011ce447f0666cdb92f459bfb7bfe2cb4/tools/shell-lib/common.sh#L134-136) which reads cluster_public_endpoint in the sylva-units-values Secret

This works but does not seem optimal:

  • when libvirt-metal (in the bootstrap environment) produces the ConfigMap, the next periodic reconciliation of sylva-units sees new values and does a new Helm release of sylva-units, which isn't really necessary or optimal
  • a side-effect (which we can compensate) is that, .Release.IsUpgrade being true on this second iteration, we have some settings that are wrongly set (cluster-reachable does not depend on cluster unit anymore), leading to confusing things like this

My first impression is that we could improve this by:

  • don't overwrite the cluster_public_endpoint via a valuesFrom
  • have retrieve_kubeconfig try to find the value in cluster-public-endpoint ConfigMap if it exists, and read from the sylva-units-values Secret if it does not exist

/cc @feleouet @mederic.deverdilhac

Assignee Loading
Time tracking Loading