[patch] Delete and recreate config-pvc when storage class changes on upgrade

[Jeel-Oza]

Problem

When mas upgrade runs and a config-pvc already exists in the pipelines namespace (created during a previous installation) with a different storageClassName than what the upgrade detects, preparePipelinesNamespace()
called applyResource() which attempted to patch the existing PVC with the new storage class. Kubernetes rejects this with a 422 Unprocessable Entity error because storageClassName is an immutable field on a PVC — it cannot be changed after creation. This caused the upgrade pipeline to never launch.

Root Cause

In python-devops/src/mas/devops/tekton.py, preparePipelinesNamespace() blindly called applyResource() without first checking whether the existing config-pvc had a different storage class. When the storage class differed, the patch hit the Kubernetes immutability constraint and failed hard, blocking the entire upgrade.

Solution

Before calling applyResource() to create the config-pvc, the storage class of any existing PVC is now compared against the detected storage class:

• Same storage class → PVC is already correct, skip delete and recreate entirely
• Different storage class → force-delete the PVC and recreate with the correct one

The force-delete handles the PVC regardless of its current state (Bound, Lost, or Terminating) by applying all unblocking steps each iteration:

1. Clear PV claimRef — sets all claimRef fields to empty strings (not null — null is ignored when the PVC already has a deletionTimestamp). This moves the PVC from Bound → Lost, causing PVCProtectionController to drop the pvc-protection finalizer voluntarily.
2. Clear PV finalizers — unblocks the PV if it is itself stuck Terminating.
3. Clear PVC finalizer and issue delete — safe once the PVC is no longer Bound.

The loop retries up to 30 times until the PVC is confirmed gone. The orphaned PV is also deleted afterwards to prevent accumulation across upgrades.

Files Changed

Repo	File	Change
python-devops	src/mas/devops/tekton.py	Storage class check + force-delete logic before PVC recreate

Testing

Verified on a fyre cluster upgrading MAS 9.0.x → 9.1.x with config-pvc bound to ocs-storagecluster-cephfs and upgrade detecting nfs-client as the default storage class. Pipeline previously failed at Preparing namespace with a 422 error. With this fix, config-pvc was deleted and recreated with the correct storage class and the upgrade pipeline launched successfully.

Acceptance Criteria

• mas upgrade launches the pipeline without error when config-pvc exists with a different storage class than the detected default
• config-pvc is not deleted when the storage class already matches
• config-pvc is recreated with the correct storage class when it differs
• Orphaned PV is cleaned up after deletion
• No regression on first-time installs where config-pvc does not yet exist