CheCluster CR storage config in devEnvironments is ignored

[amomra]

Describe the bug

We have two storage classes configured in our test K8S cluster as follows:

NAME                     PROVISIONER                      RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
che-workspaces-storage   che-workspaces-pvc-provisioner   Delete          Immediate              true                   3d17h
local-path (default)     rancher.io/local-path            Retain          WaitForFirstConsumer   false                  3d17h

I created a CheCluster resource and configured the storage as follows:

spec:
  ...
  devEnvironments:
    storage:
      pvcStrategy: per-workspace
      pvc:
        claimSize: 3Gi
        storageClass: che-workspaces-storage
  ...

But when I start a new workspace the Eclipse Che ignores this config (even PVC strategy) and create using the default storage class as follows:

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                    STORAGECLASS   REASON   AGE
pvc-ab02d41d-373a-44c2-921e-a2a7342f24c1   1Gi        RWO            Retain           Bound    eclipse-che/postgres-data                                local-path              8m25s
pvc-bc92ff34-12e1-4131-b352-0848476109c7   10Gi       RWO            Retain           Bound    che-ws-lcvmelo/claim-devworkspace                        local-path              1s

I tried to recreate all the cluster but it always create using the default storage class. Also the PVC is created using the common strategy instead of the configured per-workspace.

I think this is related to #21405

Che version

7.51@latest

Steps to reproduce

1. Create two StorageClasses: one default and another that will be used by Eclipse Che (name it che-workspaces-storage. Create PVC provisioners if necessary)
2. Start a new Che cluster with the following config:

apiVersion: org.eclipse.che/v2
kind: CheCluster
metadata:
  name: eclipse-che
  namespace: eclipse-che
spec:
  networking:
    domain: <domain>
    tlsSecretName: <TLS>

    annotations:
      kubernetes.io/ingress.class: "nginx"
      nginx.ingress.kubernetes.io/proxy-buffer-size: "8k"
      nginx.ingress.kubernetes.io/proxy-body-size: "10m"
      nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
      nginx.ingress.kubernetes.io/proxy-connect-timeout: "3600"
      nginx.ingress.kubernetes.io/ssl-redirect: "true"

    auth:
      identityProviderURL: <our internal Keycloak>
      oAuthClientName: <clientId>
      oAuthSecret: <client secret>
  devEnvironments:
    defaultNamespace:
      template: 'che-ws-<username>'
    storage:
      pvcStrategy: per-workspace
      pvc:
        claimSize: 3Gi
        storageClass: che-workspaces-storage
  components:
    devWorkspace:
      runningLimit: '2'
    
    cheServer:
      extraProperties:
        # para resolver o problema do usuário não conseguir acessar os resources do devworkspaces
        # Ref: https://github.com/eclipse/che/issues/21477
        CHE_OIDC_USERNAME__CLAIM: email
        CHE_SYSTEM_SUPER__PRIVILEGED__MODE: 'true'
        # CHE_LIMITS_USER_WORKSPACES_RAM: '6442450944' # 6 GB
        CHE_WORKSPACE_DEFAULT__MEMORY__LIMIT__MB: '0'
        CHE_WORKSPACE_SIDECAR_IMAGE__PULL__POLICY: 'IfNotPresent'
        # CHE_LIMITS_USER_WORKSPACES_RUN_COUNT: '2'
        # CHE_SYSTEM_ADMIN__NAME: 'lcvmelo'
    database:
      externalDb: false
    metrics:
      enable: true

3. Start a workspace
4. Run kubectl get pv and check that the PV was created with the default storage class instead of the configured

Expected behavior

Workspace PVC created with the configured storage class and claim size. If this configuration needs to be done in the DevWorkspace operator then the documentation in the page Configuring storage classes should be fixed.

Runtime

Kubernetes (vanilla)

Screenshots

No response

Installation method

OperatorHub

Environment

Linux

Eclipse Che Logs

No response

Additional context

No response

[ibuziuk]

I believe this is a duplicate of https://github.com/eclipse/che/issues/21405

[tolusha]

I am closing it since https://github.com/eclipse/che/issues/21405 is resolved.