Add storageClassName Support to fileStore.local Configuration

[Raptus1]

Issue Template for Mattermost Operator Repository

---

Title

[Feature Request] Add storageClassName support to fileStore.local configuration

Labels

• enhancement
• operator
• storage

---

Description

Problem Statement:

The Mattermost CustomResource currently does not support specifying a storageClassName for PersistentVolumeClaims (PVCs) created by the fileStore.local configuration. This creates deployment challenges in Kubernetes environments where:

1. No default StorageClass is configured
2. Multiple StorageClasses exist and a specific one must be used
3. Different storage performance characteristics are needed (e.g., SSD vs HDD)
4. Cloud-specific storage classes must be specified (e.g., AWS gp3, Azure Premium_LRS)

Current Behavior:

When deploying Mattermost with local file storage, the operator creates a PVC without a storageClassName, which causes:

# Current Mattermost CR spec
spec:
  fileStore:
    local:
      enabled: true
      storageSize: 10Gi
      # No way to specify storageClassName

This results in PVCs that fail to bind when no default storage class exists:

Error: no persistent volumes available for this claim and no storage class is set

Expected Behavior:

Users should be able to specify a storageClassName in their Mattermost CustomResource:

spec:
  fileStore:
    local:
      enabled: true
      storageSize: 10Gi
      storageClassName: my-storage-class  # Requested feature

---

Use Cases

1. Multi-tenant Kubernetes Clusters: Different teams may have different storage classes with varying performance characteristics and cost profiles.

2. Cloud Provider Best Practices: Cloud providers often have multiple storage class options (e.g., AWS gp2, gp3, io1; Azure Standard_LRS, Premium_LRS) that should be explicitly specified for production workloads.

3. Performance Requirements: Organizations may need to specify high-performance storage classes (NVMe, SSD-backed) for production deployments while using standard storage for development.

4. Compliance and Security: Some storage classes may have encryption or replication requirements that must be met for regulatory compliance.

5. Cost Optimization: Ability to choose cost-effective storage classes for non-production environments.

---

Proposed Solution

Add storageClassName as an optional field to the fileStore.local configuration:

# pkg/apis/mattermost/v1beta1/mattermost_types.go (or equivalent)
type FileStoreLocal struct {
    Enabled            bool   `json:"enabled"`
    StorageSize        string `json:"storageSize,omitempty"`
    StorageClassName   string `json:"storageClassName,omitempty"`  // New field
}

Implementation Details:

The operator should:

1. Accept storageClassName as an optional field in the Mattermost CR
2. Pass this value to the PVC template when creating the PersistentVolumeClaim
3. If not specified, maintain current behavior (rely on default StorageClass)
4. Validate that the specified StorageClass exists in the cluster

---

Example Usage

Development Environment:

apiVersion: installation.mattermost.com/v1beta1
kind: Mattermost
metadata:
  name: mattermost-dev
spec:
  fileStore:
    local:
      enabled: true
      storageSize: 5Gi
      storageClassName: standard

Production Environment:

apiVersion: installation.mattermost.com/v1beta1
kind: Mattermost
metadata:
  name: mattermost-prod
spec:
  fileStore:
    local:
      enabled: true
      storageSize: 50Gi
      storageClassName: ssd-premium

---

Current Workarounds

Users currently need to:

1. Set a default StorageClass in their cluster, OR
2. Manually patch PVCs after creation, OR
3. Use automation (e.g., Ansible, admission webhooks) to patch PVCs

Example workaround (not ideal):

# Wait for PVC creation
kubectl wait --for=create pvc/mattermost -n mattermost --timeout=300s

# Manually patch the PVC
kubectl patch pvc mattermost -n mattermost -p '{"spec":{"storageClassName":"my-storage-class"}}'

This workaround is:

• Not declarative
• Requires additional tooling
• Prone to race conditions
• Not documented in official deployment guides

---

Benefits of Implementation

1. Better User Experience: Aligns with standard Kubernetes practices where StorageClass is a first-class configuration option
2. Cloud-Native Best Practices: Follows the pattern established by other Kubernetes operators
3. Reduced Deployment Friction: Eliminates the need for manual PVC patching or cluster-wide default StorageClass
4. Documentation Clarity: Official deployment guides can include storage class configuration
5. Multi-Environment Support: Simplifies management of different environments with different storage requirements

---

Similar Implementations

Other Kubernetes operators that support storageClassName:

• PostgreSQL Operator: Supports storageClassName in volume configurations
• MySQL Operator: Allows storage class specification per instance
• Elasticsearch Operator: Includes storageClassName in PersistentVolumeClaim templates
• Redis Operator: Provides storage class configuration options

Example from CloudNative-PG Operator:

spec:
  storage:
    storageClass: fast-ssd
    size: 10Gi

---

Additional Context

Environment:

• Kubernetes Version: 1.28+
• Mattermost Operator Version: Latest
• Deployment Method: Helm Chart / kubectl

Related Issues:

• (Link any related issues if they exist)

Documentation References:

• Current Mattermost Operator docs don't mention storage class configuration
• Kubernetes PersistentVolumeClaim API: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#class-1

---

Questions for Maintainers

1. Is there a specific reason storageClassName was not included initially?
2. Are there backward compatibility concerns with adding this field?
3. Would you prefer this as an optional field or required field?
4. Should validation be added to check if the StorageClass exists before PVC creation?

---

Thank you for considering this feature request!