Skip to content

OSDOCS-16947#CQA work STOR3 - CSI storage class #114222

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lpettyjo wants to merge 1 commit into
base: main
Choose a base branch
from
Open

OSDOCS-16947#CQA work STOR3 - CSI storage class #114222

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions modules/persistent-storage-csi-sc-managing-cli.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,17 +7,20 @@
[id="persistent-storage-csi-sc-managing-cli_{context}"]
= Managing the default storage class using the CLI

[role="_abstract"]
Manage storage class behavior using the CLI by configuring the `ClusterCSIDriver` object's `storageClassState` field. Set the state to Managed for operator control, Unmanaged for manual control, or Removed to delete the storage class, determining how default storage classes are handled.

.Prerequisites
* Access to the cluster with cluster-admin privileges.

.Procedure

To manage the storage class using the CLI, run the following command:

* To manage the storage class using the CLI, run the following command:
+
[source,terminal]
----
$ oc patch clustercsidriver $DRIVERNAME --type=merge -p "{\"spec\":{\"storageClassState\":\"${STATE}\"}}" <1>
$ oc patch clustercsidriver $DRIVERNAME --type=merge -p "{\"spec\":{\"storageClassState\":\"${STATE}\"}}"
----
<1> Where `${STATE}` is "Removed" or "Managed" or "Unmanaged".
+
Where `$DRIVERNAME` is the provisioner name. You can find the provisioner name by running the command `oc get sc`.
** Where `${STATE}` is "Removed" or "Managed" or "Unmanaged".
** Where `$DRIVERNAME` is the provisioner name. You can find the provisioner name by running the command `oc get sc`.
10 changes: 6 additions & 4 deletions modules/persistent-storage-csi-sc-managing.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,15 +7,16 @@
[id="persistent-storage-csi-sc-managing_{context}"]
= Managing the default storage class using the web console

[role="_abstract"]
Manage storage class behavior using the web console by configuring the `ClusterCSIDriver` object's `storageClassState` field. Set the state to Managed for operator control, Unmanaged for manual control, or Removed to delete the storage class, determining how default storage classes are handled.

.Prerequisites
* Access to the {product-title} web console.

* Access to the cluster with cluster-admin privileges.

.Procedure

To manage the default storage class using the web console:

. Log in to the web console.

. Click *Administration* > *CustomResourceDefinitions*.
Expand All @@ -39,9 +40,10 @@ spec:
managementState: Managed
observedConfig: null
operatorLogLevel: Normal
storageClassState: Unmanaged <1>
storageClassState: Unmanaged
...
----
<1> `spec.storageClassState` field set to "Unmanaged"
+
For this example, `spec.storageClassState` field is set to "Unmanaged".

. Click *Save*.
5 changes: 4 additions & 1 deletion modules/persistent-storage-csi-sc-multiple-none.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,13 @@
//
// * storage/container_storage_interface/persistent-storage-csi-sc-manage.adoc
//
:_mod-docs-content-type: PROCEDURE
:_mod-docs-content-type: CONCEPT
[id="persistent-storage-csi-sc-multiple-none_{context}"]
= Absent or multiple default storage classes

[role="_abstract"]
Absent or multiple default storage classes cause persistent volume claim issues. Multiple default storage classes might result in unpredictable selection and alerts, while absent default storage classes leave claims pending. Resolve by ensuring exactly one storage class is designated as the default.

== Multiple default storage classes
Multiple default storage classes can occur if you mark a non-default storage class as default and do not unset the existing default storage class, or you create a default storage class when a default storage class is already present. With multiple default storage classes present, any persistent volume claim (PVC) requesting the default storage class (`pvc.spec.storageClassName`=nil) gets the most recently created default storage class, regardless of the default status of that storage class, and the administrator receives an alert in the alerts dashboard that there are multiple default storage classes, `MultipleDefaultStorageClasses`.

Expand Down
42 changes: 42 additions & 0 deletions modules/persistent-storage-csi-sc-overview.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
// Module included in the following assemblies:
//
// * storage/container_storage_interface/persistent-storage-csi-sc-manage.adoc
//
:_mod-docs-content-type: CONCEPT
[id="persistent-storage-csi-sc-overview_{context}"]
= Overview

[role="_abstract"]
Managing the default storage class allows you to accomplish several different objectives:

* Enforcing static provisioning by disabling dynamic provisioning.

* When you have other preferred storage classes, preventing the storage operator from re-creating the initial default storage class.

* Renaming, or otherwise changing, the default storage class

To accomplish these objectives, you change the setting for the `spec.storageClassState` field in the `ClusterCSIDriver` object. The possible settings for this field are:

* *Managed*: (Default) The Container Storage Interface (CSI) operator is actively managing its default storage class, so that most manual changes made by a cluster administrator to the default storage class are removed, and the default storage class is continuously re-created if you attempt to manually delete it.

* *Unmanaged*: You can modify the default storage class. The CSI operator is not actively managing storage classes, so that it is not reconciling the default storage class it creates automatically.

* *Removed*: The CSI operators deletes the default storage class.

ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
Managing the default storage classes is supported by the following Container Storage Interface (CSI) driver operators:

* Amazon Web Services (AWS) Elastic Block Storage (EBS)

* Azure Disk

* Azure File

* Google Cloud Platform (GCP) Persistent Disk (PD)

* {ibm-cloud-name} VPC Block

* OpenStack Cinder

* VMware vSphere
endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
37 changes: 3 additions & 34 deletions storage/container_storage_interface/persistent-storage-csi-sc-manage.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,41 +6,10 @@ include::_attributes/common-attributes.adoc[]

toc::[]

== Overview
[role="_abstract"]
Many Container Storage Interface (CSI) operators can actively manage default storage classes, removing manual intervention needs and avoiding accidental deletion. Proper management ensures persistent volume claims provision correctly with the appropriate storage backend for your applications.

Managing the default storage class allows you to accomplish several different objectives:

* Enforcing static provisioning by disabling dynamic provisioning.

* When you have other preferred storage classes, preventing the storage operator from re-creating the initial default storage class.

* Renaming, or otherwise changing, the default storage class

To accomplish these objectives, you change the setting for the `spec.storageClassState` field in the `ClusterCSIDriver` object. The possible settings for this field are:

* *Managed*: (Default) The Container Storage Interface (CSI) operator is actively managing its default storage class, so that most manual changes made by a cluster administrator to the default storage class are removed, and the default storage class is continuously re-created if you attempt to manually delete it.

* *Unmanaged*: You can modify the default storage class. The CSI operator is not actively managing storage classes, so that it is not reconciling the default storage class it creates automatically.

* *Removed*: The CSI operators deletes the default storage class.

ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
Managing the default storage classes is supported by the following Container Storage Interface (CSI) driver operators:

* xref:../../storage/container_storage_interface/persistent-storage-csi-ebs.adoc#persistent-storage-csi-ebs[Amazon Web Services (AWS) Elastic Block Storage (EBS)]

* xref:../../storage/container_storage_interface/persistent-storage-csi-azure.adoc#persistent-storage-csi-azure-disk[Azure Disk]

* xref:../../storage/container_storage_interface/persistent-storage-csi-azure-file.adoc#persistent-storage-csi-azure-file[Azure File]

* xref:../../storage/container_storage_interface/persistent-storage-csi-gcp-pd.adoc#persistent-storage-csi-gcp-pd[Google Cloud Platform (GCP) Persistent Disk (PD)]

* xref:../../storage/container_storage_interface/persistent-storage-csi-ibm-cloud-vpc-block.adoc#persistent-storage-csi-ibm-cloud-vpc-block[{ibm-cloud-name} VPC Block]

* xref:../../storage/container_storage_interface/persistent-storage-csi-cinder.adoc#persistent-storage-csi-cinder[OpenStack Cinder]

* xref:../../storage/container_storage_interface/persistent-storage-csi-vsphere.adoc#persistent-storage-vsphere[VMware vSphere]
endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
include::modules/persistent-storage-csi-sc-overview.adoc[leveloffset=+1]

include::modules/persistent-storage-csi-sc-managing.adoc[leveloffset=+1]

Expand Down