Add a test to ensure that no CRDs were recreated during an upgrade (!8487) · Merge requests · Sylva-projects / sylva-core

What does this MR do and why?

This MR introduce a new test in our current framework.

test_crd_recreation.py

This test is done in 2 steps for each cluster

During the tests running after the install phase (--phase=install) it will list all CRD of the current cluster and save their name + creation date in a configmap.

sylva-test-crd-snapshot-management
sylva-test-crd-snapshot-workload

the name of the configmap depend of the cluster kind

Configmap example:

apiVersion: v1
data:
  crd-creation-timestamps: '{"acraccesstokens.generators.external-secrets.io": "2026-07-08T06:02:07Z", "alerts.notification.toolkit.fluxcd.io": "2026-07-08T05:58:23Z", "amazonec2configs.rke-machine-config.cattle.io": "2026-07-08T06:17:01Z", "amazonec2machines.rke-machine.cattle.io": "2026-07-08T06:17:01Z", "amazonec2machinetemplates.rke-machine.cattle.io": "2026-07-08T06:17:01Z", "apiservers.operator.tigera.io": "2026-07-08T05:55:50Z", "apiservices.management.cattle.io": "2026-07-08T06:16:49Z", "apps.catalog.cattle.io": "2026-07-08T06:16:49Z", "artifactgenerators.source.extensions.fluxcd.io": "2026-07-08T05:58:23Z", "auditpolicies.auditlog.cattle.io": "2026-07-08T06:16:48Z", "auditrequestheaders.redhatcop.redhat.io": "2026-07-08T06:03:53Z", "audits.redhatcop.redhat.io": "2026-07-08T06:03:53Z", "authconfigs.management.cattle.io": "2026-07-08T06:16:50Z", "authenginemounts.redhatcop.redhat.io": "2026-07-08T06:03:53Z", "azureauthengineconfigs.redhatcop.redhat.io": "2026-07-08T06:03:53Z", "azureauthengineroles.redhatcop.redhat.io": "2026-07-08T06:03:53Z", "azureconfigs.rke-machine-config.cattle.io": "2026-07-08T06:17:01Z", "azuremachines.rke-machine.cattle.io": "2026-07-08T06:17:01Z", "azuremachinetemplates.rke-machine.cattle.io": "2026-07-08T06:17:01Z", "azuresecretengineconfigs.redhatcop.redhat.io": "2026-07-08T06:03:53Z", "azuresecretengineroles.redhatcop.redhat.io": "2026-07-08T06:03:53Z", "backups.postgresql.cnpg.io": "2026-07-08T06:02:06Z", "backups.resources.cattle.io": "2026-07-08T06:02:05Z", ....."}'
kind: ConfigMap
metadata:
  creationTimestamp: "2026-07-08T08:51:46Z"
  name: sylva-test-crd-snapshot-management
  namespace: sylva-system
  resourceVersion: "156277"
  uid: 4c4cd43a-bb61-4cf6-b08b-60ae7184235a

Second part of the test happen after the upgrade (--phase=upgrade)

it will first try to retrieve the configmap, if not found the test is properly skipped
If the configmap is found it will compare it to the current CRDs present in the cluster
If any CRDs are missing they will be either:
- reported in log info if they are in _ALLOWED_DELETED_CRDS
- if not in _ALLOWED_DELETED_CRDS the test will failed, and these crd will be reported eg:
```
E   Failed: The following CRD(s) were deleted during upgrade (add to _ALLOWED_DELETED_CRDS if intentional):
- fakeresources.sylva-test.io
```
If any CRDs were recreated, the test will failed with an explicit error:

eg:

E   Failed: The following CRD(s) were recreated during upgrade (creationTimestamp changed), which destroys all existing custom resources of that type:
      - fakeresources.sylva-test.io: install=2026-07-08T08:50:03Z  upgrade=2026-07-08T08:50:31Z

Configmap are dump as artifacts for later debugging purpose. And their are deleted at the end of the second tests to keep the PF clean

This code was mainly generated with copilot (claude 4.6), manually tested on a local deployment and manually reviewed

close #4346 (closed)

Test coverage

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.

[urlcrd-snapshot-upgrade.json

crd-snapshot-install.json](url)

Edited Jul 08, 2026 by Thomas Morin

Add a test to ensure that no CRDs were recreated during an upgrade

What does this MR do and why?

Related reference(s)

Test coverage

CI configuration

Global config for deployment pipelines

Merge request reports