improve tuning of sylvactl/unitTimeout for cluster* units, in particular on libvirt-metal (!7418) · Merge requests · Sylva-projects / sylva-core

Closes #3855 (closed)

The primary goal for this MR is to reduce the timeout for cluster unit, and related units relying on the same timeout, for libvirt-metal testing.

Here is what this MR does:

restructure the code that computes the way the timeout is computed:
- to avoid having too much conditionality "if infra is xxx", I introduced a node_create_timeout_per_infra side-by-side to node_create_timeout
- I realized that the computation was subtlely wrong and fixed it:
  - not taking into account cluster_maxunavailable_enabled (which was introduced after)
  - for "fresh install", the computation wasn't reflecting well the fact that MD nodes start to build once the first CP node is built
pick better default values
- I used using a small sample of CI deployments (capo, libvirt-metal capm3, and real capm3)
- I retro-computed the "node creation time" and "node drain time" based on the time each pipepine took between start of reconciliation of cluster unit and then end of reconciliation of cluster-machines-ready, using fresh install pipelines to estimate "node creation time" and "rolling-update" pipelines (combined with the "node creation time" estimate) to compute the "node drain time"
rename "node creation/drain timeout" as "node creation/drain time" because these variables contain something which is a time (an estimation of a time) and not something which is a timeout; it's only a computation based on those estimates that is a timeout
since the default values are lower, to not risk a CI degradation, I also added a 5 minute margin to the final result
simplify the call to include "cluster-unit-timeout" . from values.yaml avoiding the printf (.. | int)
other simplifications in "cluster-unit-timeout" (there were a few useless intermediate variables)

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon	Meaning	Available values
☁️	Infra Provider	`capd`, `capo`, `capm3`
🚀	Bootstrap Provider	`kubeadm` (alias `kadm`), `rke2`, `okd`, `ck8s`
🐧	Node OS	`ubuntu`, `suse`, `na`, `leapmicro`
🛠️	Deployment Options	Deployment option list and description
🎬	Pipeline Scenarios	Available scenario list and description
🟢	Enabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🔴	Disabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🏗️	Target platform	Can be used to select specific deployment environment (i.e `real-bmh` for capm3 )

Global config for deployment pipelines

autorun pipelines
allow failure on pipelines
record sylvactl events

Notes:

Enabling autorun will make deployment pipelines to be run automatically without human interaction
Disabling allow failure will make deployment pipelines mandatory for pipeline success.
if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.

Edited Apr 02, 2026 by Thomas Morin

improve tuning of sylvactl/unitTimeout for cluster* units, in particular on libvirt-metal

CI configuration

Global config for deployment pipelines

Merge request reports