Fix Rancher UI becoming unresponsive, caused by the chainsaw test CRD churn (!8739) · Merge requests · Sylva-projects / sylva-core

What does this MR do and why?

The deny-cabundle-changes chainsaw test used to delete the dummy CRD it creates. Deleting/recreating a CRD on every test run is causing the following behavior on a cluster running Rancher: The apiserver has to run the CRD cleanup finalizer, which reads the per-CRD storage and because the test rewrites the CRD spec several times just before deleting it, that storage is still re-initializing. Downstream, Rancher's steve/cattle-agent reacts to the type appearing and disappearing by re-listing and rebuilding its schemas and re-dialing the aggregation server, which leaves the UI unresponsive. Keeping the CRD in place removes this churn.

The first commit keeps the tests.example.com CRD after the chainsaw test, by removing the cleanup step.

The second commit makes the test idempotent, now that the CRD survives Since the test suite is re-run on the same cluster (the chainsaw Job is recreated at each sylva-units revision), it must cope with a CRD left over from a previous run whose caBundle is already set:

a new step right after the CRD setup resets the caBundle to a known value; it impersonates cert-manager, as the policy under test (rightfully) forbids any other updater from changing a caBundle
the caBundle the suite leaves behind (modify-post-annotation-removal.yaml) now uses a cert distinct from the one in add-cabundle.yaml, so the "reject updater attempting to add caBundle" step is always a real change, and hence really gets denied

This second commit was authored by Claude Opus 5.

Although we worked together, most of the effort and credits go to @bogdan.antohe, which spent a large amount of time tackling this. Huge thanks!

Closes #4184 (closed)

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 Available platform list and description
⚡	Pipeline control	`autorun`, `manual` or `blocking`. Can be used to override global config and start a deployment pipeline the required way

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 Aug 05, 2026 by Dragos Gerea

Fix Rancher UI becoming unresponsive, caused by the chainsaw test CRD churn

What does this MR do and why?

Related reference(s)

CI configuration

Global config for deployment pipelines

Merge request reports