Request for a KEP

[Lazhar Halleb]

Hello SIG-storage 

I am requesting this improvement to StorageClass CR:

1. Outline the proposed title of this feature request.

   1. Improve the StorageClass CR structure

2. What is the nature and problem description of the request?

   1. Standardize the CR so that is become like most of the other CR on K8S/Openshift

   2. This improves readability

3. Are there any Documentation Requirements for this request?

4. 1. Yes, the doc needs updates

5. What is the urgency of the request?

   1. No urgency. Best Effort

6. Please provide contact information, in case of follow up questions.

   1. lha...@redhat.com

This is a sample of the current storageClass structure:

allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    description: Provides RWO Filesystem volumes, and RWO and RWX Block volumes
  name: ocs-storagecluster-ceph-rbd
parameters:
  clusterID: openshift-storage
  csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
  csi.storage.k8s.io/fstype: ext4
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
  csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
  imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
  imageFormat: "2"
  pool: ocs-storagecluster-cephblockpool
provisioner: openshift-storage.rbd.csi.ceph.com
reclaimPolicy: Delete
volumeBindingMode: Immediate

What will look like the new CR:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    description: Provides RWO Filesystem volumes, and RWO and RWX Block volumes
  name: ocs-storagecluster-ceph-rbd
spec:
  allowVolumeExpansion: true
  parameters:
    clusterID: openshift-storage
    csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
    csi.storage.k8s.io/fstype: ext4
    csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
    csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
    csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
    imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
    imageFormat: "2"
    pool: ocs-storagecluster-cephblockpool
  provisioner: openshift-storage.rbd.csi.ceph.com
  reclaimPolicy: Delete
  volumeBindingMode: Immediate
status:
  ready status: TBD

Many thanks

[Jan Šafránek]

Can you please write a Kubernetes issue? Especially please elaborate on the reason why. "Standardize the CR so that is become like most of the other CR on K8S/Openshift" does not look appealing to me, there are many Kubernetes objects that don't have spec/status structure. Especially those that contain configuration observed by potentially many components, e.g. a ConfigMap or RuntimeClass.

Jan

--
You received this message because you are subscribed to the Google Groups "sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sig-storage...@kubernetes.io.
To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-storage/78a49309-f991-40f2-b6ef-a2845f0b0434n%40kubernetes.io.

[Lazhar Halleb]

Hi

I agree with you that not all Kubernetes CRs have a spec field where most of data is stored underneath it, but I see that the structure of the storageClass one can be improved.

Can we improve the structure here? Definitely yes.

When you say: "write Kubernetes issue," do you have a platform where I can write it? or a form to follow?

Thanks

[Jan Šafránek]

I meant filling an issue in https://github.com/kubernetes/kubernetes/issues with `/sig storage` somewhere in the issue description, so it gets routed to the right people.

On Wednesday, May 6, 2026 at 2:10:30 AM UTC+2 Lazhar Halleb wrote:

Hi

I agree with you that not all Kubernetes CRs have a spec field where most of data is stored underneath it, but I see that the structure of the storageClass one can be improved.

Can we improve the structure here? Definitely yes.

For any change in the Kubernetes API, we need a strong reason why is the change needed. "It would look better" is not good enough. Do you have a use case that is **not possible** to implement with the existing API?

Jan