Fix phoenix-db PVC storage class rejected by admission webhook

[majamassarini]

rh-internal-iscsi is deprecated; the cluster requires netapp-iscsi.

Assisted-by: Claude Opus 4.6 (1M context) noreply@anthropic.com

[qodo-for-packit]

PR Summary by Qodo

Fix phoenix-db PVC by switching to netapp-iscsi storage class

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Switch phoenix-db PVC to the supported netapp-iscsi StorageClass.
• Prevent PVC admission webhook rejections caused by deprecated rh-internal-iscsi.

Diagram

graph TD
  A["openshift/pvc-phoenix-db-data.yml"] --> B["Phoenix DB PVC"] --> C[("StorageClass: netapp-iscsi")] --> D["OpenShift cluster"]
  D --> E["Admission webhook"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Rely on the cluster default StorageClass (omit storageClassName)

• ➕ Avoids hard-coding a specific StorageClass name
• ➕ Reduces churn when StorageClass names change
• ➖ Behavior changes if the default StorageClass is modified
• ➖ Less explicit; can surprise operators during cluster migrations

2. Make storageClassName environment-specific via Kustomize overlays/Helm values

• ➕ Supports different clusters (dev/stage/prod) without code changes
• ➕ Safer future migrations by changing only overlay/values
• ➖ Adds configuration structure/complexity
• ➖ Requires standardizing deployment tooling if not already in place

Recommendation: The direct switch to netapp-iscsi is appropriate to immediately unblock PVC admission. If this repo targets multiple OpenShift environments, consider a follow-up to parameterize storageClassName (overlay/value) or intentionally rely on the default StorageClass to reduce future deprecation-driven edits.

Files changed (1) +1 / -1

Other (1) +1 / -1

pvc-phoenix-db-data.ymlSwitch phoenix-db PVC to netapp-iscsi StorageClass +1/-1

Switch phoenix-db PVC to netapp-iscsi StorageClass

• Replaces the deprecated rh-internal-iscsi storageClassName with netapp-iscsi to satisfy cluster admission requirements and allow the PVC to be created/bound successfully.

openshift/pvc-phoenix-db-data.yml

[qodo-for-packit]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 7 rules

1. PVC storageClass redeploy break ✗ Dismissed 🐞 Bug ☼ Reliability

Description

If phoenix-db-data PVC already exists in the cluster, re-running ./openshift/deploy.sh will
attempt to oc apply a different spec.storageClassName, which cannot be updated on an existing
PVC and will block redeploys/updates.

Code

openshift/pvc-phoenix-db-data.yml[16]

+  storageClassName: netapp-iscsi

Relevance

⭐⭐⭐ High

Team documents PVC immutability/cleanup risks (PR #691); deploy reliability concerns commonly
addressed in OpenShift changes (PR #443).

PR-#691
PR-#443

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR changes the PVC’s storage class, and the repo’s deployment workflow re-applies that PVC
manifest on every run, making the change operationally risky for existing installs.

openshift/pvc-phoenix-db-data.yml[10-17]
openshift/deploy.sh[7-55]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Changing `spec.storageClassName` on an existing PVC is not safely roll-forward via `oc apply`. This PR updates `phoenix-db-data` to `netapp-iscsi`, which will cause `./openshift/deploy.sh` to fail on clusters where the PVC already exists (created with the previous class).

### Issue Context
`openshift/deploy.sh` applies the PVC manifest on every deployment run. If the PVC exists, `oc apply` will attempt to patch the spec, which will be rejected for immutable PVC fields, preventing further deployment steps.

### Fix Focus Areas
- openshift/pvc-phoenix-db-data.yml[16-16]
- openshift/deploy.sh[7-55]
- openshift/README.md[65-92]

### What to change
Implement an explicit upgrade/migration strategy, e.g. one of:
1) **Safe default**: in `deploy.sh`, detect an existing `phoenix-db-data` PVC and **skip applying** the PVC manifest (or exit with a clear message) when it already exists, so redeploys don’t fail.
2) **Versioned PVC**: create a new PVC name (e.g., `phoenix-db-data-v2`) and update `deployment-phoenix-db.yml` to reference it; document a data migration procedure.
3) **Operator/manual step**: document that changing storageClassName requires manual intervention (and what the safe steps are for preserving DB data).

Make sure the chosen approach avoids accidental data loss (this PVC backs PostgreSQL data).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Storage class docs outdated ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The OpenShift deployment README only demonstrates validating netapp-nfs, but this PR makes
phoenix-db-data require netapp-iscsi, leaving operators without repo guidance to
validate/provision the DB storage class used by the manifests.

Code

openshift/pvc-phoenix-db-data.yml[16]

+  storageClassName: netapp-iscsi

Relevance

⭐⭐⭐ High

OpenShift README is actively maintained alongside deploy changes (PR #443, #487); storageClass
change likely expected to be documented.

PR-#443
PR-#487

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Repo documentation only references validating netapp-nfs, while the updated DB PVC manifest now
hard-requires netapp-iscsi.

openshift/README.md[65-86]
openshift/pvc-phoenix-db-data.yml[10-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`openshift/README.md` documents testing a storage class using `netapp-nfs`, but the manifests now also require `netapp-iscsi` for the Phoenix DB PVC. This is an operator footgun during cluster bring-up.

### Issue Context
Most PVCs use `netapp-nfs`, but `phoenix-db-data` uses `netapp-iscsi`. The README’s validation snippet and guidance should reflect that there are multiple required storage classes.

### Fix Focus Areas
- openshift/README.md[65-86]
- openshift/pvc-phoenix-db-data.yml[16-16]

### What to change
Update `openshift/README.md` to:
- Mention that the deployment uses **both** `netapp-nfs` and `netapp-iscsi` (and which components use which).
- Optionally provide a second throwaway PVC example using `storageClassName: netapp-iscsi` so operators can validate it before running `deploy.sh`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---