The LVMS feature “Introduce configurable StorageClass options” assumes that changes to storageClassOptions can be applied as Day-2 operations and reconciled onto existing StorageClasses.

This spike investigates whether:

• All proposed StorageClass fields are actually mutable in Kubernetes

• LVMS already reconciles these fields correctly

• Additional logic or guardrails are required

The goal is to validate whether the Day-2 requirement is truly needed, partially needed, or already handled by existing LVMS reconciliation logic.

Problem Statement

The feature requirements state:

StorageClassOptions can be changed as Day-2 operations — any change is applied to the existing StorageClass.

However:

• Some StorageClass fields are immutable or effectively unsafe to change

• Kubernetes may accept updates but not apply them meaningfully

• LVMS reconciliation behavior may already overwrite or ignore changes

This spike ensures correctness before implementation.

Spike Objectives

This spike is complete when the following questions are answered:

1. Which StorageClass fields are mutable after creation?

• • reclaimPolicy

• • volumeBindingMode

• • .parameters

• • .metadata.labels

1. What happens when these fields are updated:

• • Before any PVC exists?

• • After PVCs already exist?

• • After Pods are scheduled?

1. Does LVMS already reconcile these fields on Day-2?

• • If yes, what behavior exists today?

• • If partially, what gaps exist?

1. Do any fields require:

• • Special handling?

• • Documentation warnings?

• • Explicit immutability enforcement?