Allow LVMS users to configure StorageClass options (reclaimPolicy, volumeBindingMode, custom parameters/labels) at the DeviceClass level for greater storage flexibility.

As a cluster administrator,
I want to configure StorageClass options per DeviceClass,
So that I can customize storage behavior without manually managing StorageClasses.

Key Benefits

• Data protection: Set Retain policy to prevent accidental deletion
• Flexible provisioning: Choose topology-aware vs immediate binding
• Custom parameters: Pass CSI driver-specific settings
• Organization: Add labels for monitoring and governance
• Day-2 updates: Modify configurations post-deployment

API Structure

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
spec:
  storage:
    deviceClasses:
      - name: vg1
        storageClassOptions:
          reclaimPolicy: Retain              # Delete (default) | Retain
          volumeBindingMode: WaitForFirstConsumer  # WaitForFirstConsumer (default) | Immediate
          additionalParameters:
            custom-iops: "3000"
          additionalLabels:
            environment: production

Acceptance Criteria

Functional Requirements

•  Support reclaimPolicy (Delete/Retain)
•  Support volumeBindingMode (Immediate/WaitForFirstConsumer)
•  Support additionalParameters map
•  Support additionalLabels map
•  All fields optional with backward-compatible defaults

Validation

•  Warn when additionalParameters conflict with LVMS-owned keys (topolvm.io/device-class, csi.storage.k8s.io/fstype)
•  Reject invalid label keys
•  StorageClassOptions is mutable (day-2 changes allowed)

Controller Behavior

•  Apply options to generated StorageClasses
•  Delete+recreate StorageClass for immutable field changes (reclaimPolicy, volumeBindingMode, parameters)
•  Update labels in-place (no recreation)
•  Protect LVMS-owned parameters and labels from override
•  Log clear messages on StorageClass recreation

Day-2 Operations

•  Existing PVCs unaffected by StorageClass changes
•  Brief window (<1s) where new PVC creation may fail during recreation

Technical Implementation

Kubernetes Constraint

StorageClass reclaimPolicy, volumeBindingMode, and parameters are immutable per Kubernetes design.

Solution: Delete+recreate pattern for immutable fields; in-place update for labels.

Protected Keys/Labels

LVMS-Owned Parameters (cannot be overridden):

• topolvm.io/device-class
• csi.storage.k8s.io/fstype

LVMS-Managed Labels (cannot be overridden):

• app.kubernetes.io/part-of
• app.kubernetes.io/name
• app.kubernetes.io/managed-by
• app.kubernetes.io/component

Known Limitations

1. Non-atomic recreation: <1s window where StorageClass doesn't exist during updates
2. PVC safety: Existing PVCs store provisioning info; unaffected by StorageClass changes
3. No parameter validation: LVMS cannot validate CSI driver-specific parameters

Testing Requirements

• Unit tests: Webhook validation, controller logic
• E2E tests: Creation, day-2 updates, recreation verification
• Manual testing: Multi-zone clusters, upgrade scenarios