Call capm3NetworkValidation

What does this MR do and why?

Closes sylva-projects/sylva-elements/helm-charts/sylva-capi-cluster#70 (closed)

Calls sylva-library defined capm3NetworkValidation named template (introduced in sylva-projects/sylva-elements/helm-charts/sylva-library!27 (merged)) to check that:

• .cluster.cluster_virtual_ip is inside the subnet of .cluster.capm3.primary_pool_network, for empty .cluster.metallb.bgp_lbs and .cluster.kube_vip.bgp_lbs
• .cluster.cluster_virtual_ip is not equal to .capm3.primary_pool_gateway
• .cluster.cluster_virtual_ip is not inside the range defined by .cluster.capm3.primary_pool_start and .cluster.capm3.primary_pool_end

Related reference(s)

Test coverage

# trying with .cluster.cluster_virtual_ip=10.188.36.148

$ helm template charts/sylva-units/ --values environment-values/rke2-capm3/values.yaml --values charts/sylva-units/management.values.yaml
Error: execution error at (sylva-units/templates/capm3-network-checks.yaml:2:29): The IP used to expose kube-api and LoadBalancer services (.cluster_virtual_ip) '10.188.36.148' is inside the range of .capm3.primary_pool_* '10.188.36.148-10.188.36.148'. This is wrong, as it may be allocated to a baremetal node.

Use --debug flag to render out invalid YAML

CI configuration

CI pipelines perform an update for both management and workload clusters, this update will NOT perform a ClusterAPI rolling update (deletion and creation of new K8s nodes) by default.

For some cases, it may be relevant to perform more complex tests.

Theses features can be activated in an MR by adding one of these labels to the MR and will apply to the next pipelines.

• adding the label ci-featuretest-rolling-update pipelines will perform a node rolling update in the -update jobs (without version upgrades)
• adding the label ci-featuretest-upgrade-from-1.1.1 pipelines will perform an upgrade from Sylva 1.1.1 to your dev branch (including a k8s version upgrade resulting in a node rolling update)