Back to bug 2112929
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| RHEL Program Management | 2022-08-01 14:34:27 UTC | Keywords | FutureFeature | |
| RHEL Program Management | 2022-08-01 14:37:55 UTC | Keywords | FutureFeature | |
| Keywords | FutureFeature | |||
| Nitin Goyal | 2022-08-01 14:44:49 UTC | Component | odf-operator | ocs-operator |
| Assignee | nigoyal | jrivera | ||
| CC | madam, sostapov | |||
| Matthias Muench | 2022-08-02 11:39:13 UTC | CC | mmuench | |
| Mike Hackett | 2022-09-13 15:03:49 UTC | Flags | needinfo?(jrivera) | |
| CC | mhackett | |||
| Nitin Goyal | 2022-10-11 15:21:19 UTC | CC | nigoyal | |
| Mike Hackett | 2022-11-08 15:56:23 UTC | Flags | needinfo?(jrivera) | |
| Mike Hackett | 2022-12-13 13:58:41 UTC | Flags | needinfo?(muagarwa) | |
| Mudit Agarwal | 2022-12-16 04:55:21 UTC | Assignee | jrivera | nigoyal |
| Flags | needinfo?(jrivera) needinfo?(muagarwa) | needinfo?(etamir) | ||
| CC | etamir | |||
| Eran Tamir | 2022-12-18 10:55:32 UTC | Flags | needinfo?(etamir) | |
| Red Hat Bugzilla | 2023-01-01 05:52:42 UTC | CC | mhackett | |
| Red Hat Bugzilla | 2023-01-01 08:44:18 UTC | CC | sostapov | |
| Alasdair Kergon | 2023-01-04 05:43:50 UTC | CC | sostapov | |
| Alasdair Kergon | 2023-01-04 11:29:24 UTC | CC | mhackett | |
| Red Hat Bugzilla | 2023-01-16 08:27:28 UTC | CC | jrivera | |
| Red Hat Bugzilla | 2023-01-31 22:28:02 UTC | CC | etamir | |
| Red Hat Bugzilla | 2023-01-31 23:39:12 UTC | CC | madam | |
| Martin Bukatovic | 2023-02-06 09:46:16 UTC | QA Contact | mbukatov | |
| Nikhil Ladha | 2023-05-25 05:59:04 UTC | CC | nladha | |
| Assignee | nigoyal | nladha | ||
| Nikhil Ladha | 2023-05-26 06:27:16 UTC | Status | NEW | ASSIGNED |
| Link ID | Github red-hat-storage/ocs-operator/pull/2059 | |||
| Nikhil Ladha | 2023-06-14 10:25:09 UTC | Status | ASSIGNED | POST |
| Mudit Agarwal | 2023-08-01 15:12:22 UTC | Flags | needinfo?(jrivera) | needinfo?(nladha) |
| Doc Type | If docs needed, set a value | Enhancement | ||
| Status | POST | MODIFIED | ||
| Nikhil Ladha | 2023-08-02 06:32:52 UTC | Doc Text | Feature: Users can customize the StorageClass name(s) while deploying ODF by updating the StorageCluster CR. The `Spec.ManagedResources`, `NFS` and the `Encryption` field in the StorageCluster CR could be updated to add a StorageClassName field under the provisioner for which the user wants to customize the StorageClass name. Ref- spec: managedResources: cephFilesystems: storageClassName: <enter-a-custom-storage-classname> cephObjectStores: storageClassName: <enter-a-custom-storage-classname> cephBlockPools: storageClassName: <enter-a-custom-storage-classname> cephNonResilientPools: storageClassName: <enter-a-custom-storage-classname> nfs: storageClassName: <enter-a-custom-storage-classname> encryption: storageClassName: <enter-a-custom-storage-classname> Reason: This will allow the user to use the same StorageClass for both internal, external mode of deployments and avoid creation of extra resources. Result: 1 StorageClass for both internal and external mode of deployment is consumed by ODF. | |
| Flags | needinfo?(nladha) | |||
| Red Hat Bugzilla | 2023-08-03 08:31:02 UTC | CC | ocs-bugs | |
| Nikhil Ladha | 2023-08-08 12:18:46 UTC | Doc Text | Feature: Users can customize the StorageClass name(s) while deploying ODF by updating the StorageCluster CR. The `Spec.ManagedResources`, `NFS` and the `Encryption` field in the StorageCluster CR could be updated to add a StorageClassName field under the provisioner for which the user wants to customize the StorageClass name. Ref- spec: managedResources: cephFilesystems: storageClassName: <enter-a-custom-storage-classname> cephObjectStores: storageClassName: <enter-a-custom-storage-classname> cephBlockPools: storageClassName: <enter-a-custom-storage-classname> cephNonResilientPools: storageClassName: <enter-a-custom-storage-classname> nfs: storageClassName: <enter-a-custom-storage-classname> encryption: storageClassName: <enter-a-custom-storage-classname> Reason: This will allow the user to use the same StorageClass for both internal, external mode of deployments and avoid creation of extra resources. Result: 1 StorageClass for both internal and external mode of deployment is consumed by ODF. | Feature: Users can customise the StorageClass name(s) while deploying a *new* ODF cluster on *CLI* (UI not supported) by updating the StorageCluster CR. The `Spec.ManagedResources.CephFilesystems`, `Spec.ManagedResources.CephBlockPools`, `Spec.ManagedResources.CephNonResilientPools`, `Spec.ManagedResources.CephObjectStores` `NFS` and the `Encryption` are the fields that can be updated in the StorageCluster CR, the user can choose to only update the fields (i.e, SC provisioner) which they are making use of and customise the StorageClass name. Ref- spec: managedResources: cephFilesystems: storageClassName: <enter-a-custom-storage-classname> cephObjectStores: storageClassName: <enter-a-custom-storage-classname> cephBlockPools: storageClassName: <enter-a-custom-storage-classname> virtualizationStorageClassName: <enter-a-custom-storageclass-name-for-virtualization-sc> cephNonResilientPools: storageClassName: <enter-a-custom-storage-classname> nfs: storageClassName: <enter-a-custom-storage-classname> encryption: storageClassName: <enter-a-custom-storage-classname> Reason: This will allow the user to use the same StorageClass for both internal, external mode of deployments and avoid creation of extra resources. Result: 1 StorageClass for both internal and external mode of deployment is consumed by ODF. |
| Nikhil Ladha | 2023-08-09 07:10:51 UTC | Doc Text | Feature: Users can customise the StorageClass name(s) while deploying a *new* ODF cluster on *CLI* (UI not supported) by updating the StorageCluster CR. The `Spec.ManagedResources.CephFilesystems`, `Spec.ManagedResources.CephBlockPools`, `Spec.ManagedResources.CephNonResilientPools`, `Spec.ManagedResources.CephObjectStores` `NFS` and the `Encryption` are the fields that can be updated in the StorageCluster CR, the user can choose to only update the fields (i.e, SC provisioner) which they are making use of and customise the StorageClass name. Ref- spec: managedResources: cephFilesystems: storageClassName: <enter-a-custom-storage-classname> cephObjectStores: storageClassName: <enter-a-custom-storage-classname> cephBlockPools: storageClassName: <enter-a-custom-storage-classname> virtualizationStorageClassName: <enter-a-custom-storageclass-name-for-virtualization-sc> cephNonResilientPools: storageClassName: <enter-a-custom-storage-classname> nfs: storageClassName: <enter-a-custom-storage-classname> encryption: storageClassName: <enter-a-custom-storage-classname> Reason: This will allow the user to use the same StorageClass for both internal, external mode of deployments and avoid creation of extra resources. Result: 1 StorageClass for both internal and external mode of deployment is consumed by ODF. | Feature: Users can customise the StorageClass name(s) while deploying a *new* ODF cluster on *CLI* (UI not supported) by updating the StorageCluster CR. The `Spec.ManagedResources.CephFilesystems`, `Spec.ManagedResources.CephBlockPools`, `Spec.ManagedResources.CephNonResilientPools`, `Spec.ManagedResources.CephObjectStores` `NFS` and the `Encryption` are the fields that can be updated in the StorageCluster CR, the user can choose to only update the fields (i.e, SC provisioner) which they are making use of and customise the StorageClass name. Ref- spec: managedResources: cephFilesystems: storageClassName: <enter-a-custom-storage-classname> cephObjectStores: storageClassName: <enter-a-custom-storage-classname> cephBlockPools: storageClassName: <enter-a-custom-storage-classname> virtualizationStorageClassName: <enter-a-custom-storageclass-name-for-virtualization-sc> cephNonResilientPools: storageClassName: <enter-a-custom-storage-classname> nfs: storageClassName: <enter-a-custom-storage-classname> encryption: storageClassName: <enter-a-custom-storage-classname> **NOTE:** The feature is mainly for *new* deployments, but if a user wants to cutomise the storageclass names in an upgraded cluster then there are a few edge cases that needs to be considered: 1. For an internal mode cluster, after updating the CR with custom storageclass names the new SCs will be created but the older one's would still exist, and they can only be deleted if no other resources are using it. 2. For an external mode cluster, after the deployment the user can edit the CR and add the custom storageclass names to it, but the change (new SCs) would only come into effect if the user updates the `data.external_cluster_details` field in the `rook-ceph-external-cluster-details` secret that contains the external cluster data. Reason: This will allow the user to use the same StorageClass for both internal, external mode of deployments and avoid creation of extra resources. Result: 1 StorageClass for both internal and external mode of deployment is consumed by ODF. |
| Nikhil Ladha | 2023-08-09 08:11:33 UTC | Doc Text | Feature: Users can customise the StorageClass name(s) while deploying a *new* ODF cluster on *CLI* (UI not supported) by updating the StorageCluster CR. The `Spec.ManagedResources.CephFilesystems`, `Spec.ManagedResources.CephBlockPools`, `Spec.ManagedResources.CephNonResilientPools`, `Spec.ManagedResources.CephObjectStores` `NFS` and the `Encryption` are the fields that can be updated in the StorageCluster CR, the user can choose to only update the fields (i.e, SC provisioner) which they are making use of and customise the StorageClass name. Ref- spec: managedResources: cephFilesystems: storageClassName: <enter-a-custom-storage-classname> cephObjectStores: storageClassName: <enter-a-custom-storage-classname> cephBlockPools: storageClassName: <enter-a-custom-storage-classname> virtualizationStorageClassName: <enter-a-custom-storageclass-name-for-virtualization-sc> cephNonResilientPools: storageClassName: <enter-a-custom-storage-classname> nfs: storageClassName: <enter-a-custom-storage-classname> encryption: storageClassName: <enter-a-custom-storage-classname> **NOTE:** The feature is mainly for *new* deployments, but if a user wants to cutomise the storageclass names in an upgraded cluster then there are a few edge cases that needs to be considered: 1. For an internal mode cluster, after updating the CR with custom storageclass names the new SCs will be created but the older one's would still exist, and they can only be deleted if no other resources are using it. 2. For an external mode cluster, after the deployment the user can edit the CR and add the custom storageclass names to it, but the change (new SCs) would only come into effect if the user updates the `data.external_cluster_details` field in the `rook-ceph-external-cluster-details` secret that contains the external cluster data. Reason: This will allow the user to use the same StorageClass for both internal, external mode of deployments and avoid creation of extra resources. Result: 1 StorageClass for both internal and external mode of deployment is consumed by ODF. | Feature: Users can customise the StorageClass name(s) while creating the StorageCluster CR during the deployment of a *new* ODF cluster on *CLI* (UI not supported). The `Spec.ManagedResources.CephFilesystems`, `Spec.ManagedResources.CephBlockPools`, `Spec.ManagedResources.CephNonResilientPools`, `Spec.ManagedResources.CephObjectStores` `NFS` and the `Encryption` are the fields that can be updated in the StorageCluster CR, the user can choose to only update the fields (i.e, SC provisioner) which they are making use of and customise the StorageClass name. Ref- spec: managedResources: cephFilesystems: storageClassName: <enter-a-custom-storage-classname> cephObjectStores: storageClassName: <enter-a-custom-storage-classname> cephBlockPools: storageClassName: <enter-a-custom-storage-classname> virtualizationStorageClassName: <enter-a-custom-storageclass-name-for-virtualization-sc> cephNonResilientPools: storageClassName: <enter-a-custom-storage-classname> nfs: storageClassName: <enter-a-custom-storage-classname> encryption: storageClassName: <enter-a-custom-storage-classname> **NOTE:** The feature is mainly for *new* deployments, but if a user wants to cutomise the storageclass names in an upgraded cluster then there are a few edge cases that needs to be considered: 1. For an internal mode cluster, after updating the CR with custom storageclass names the new SCs will be created but the older one's would still exist, and it's their choice to keep or delete them as per their usage. 2. For an external mode cluster, after the deployment the user can edit the CR and add the custom storageclass names to it, but the change (new SCs) would only come into effect if the user updates the `data.external_cluster_details` field in the `rook-ceph-external-cluster-details` secret that contains the external cluster data. Reason: This will allow the user to use the same StorageClass for both internal, external mode of deployments and avoid creation of extra resources. Result: 1 StorageClass for both internal and external mode of deployment is consumed by ODF. |
| Elad | 2023-08-09 17:00:43 UTC | CC | odf-bz-bot |
Back to bug 2112929