-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
OSDOCS-5179:Retroacitve default SC assignment
- Loading branch information
Lisa Pettyjohn
committed
Feb 10, 2023
1 parent
76868f7
commit e092666
Showing
1 changed file
with
50 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,50 @@ | ||
// Module included in the following assemblies: | ||
// | ||
// persistent-storage-csi-sc-manage | ||
// | ||
:_content-type: PROCEDURE | ||
[id="persistent-storage-csi-sc-multiple-none_{context}"] | ||
= Absent or multiple default storage classes | ||
|
||
== 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, and the administrator receives an alert that there are multiple default storage classes. | ||
|
||
== Absent default storage class | ||
There are two possible scenarios where PVCs can attempt to use a non-existent default storage class: | ||
|
||
* An administrator removes the default storage class or marks it as non-default, and then a user creates a PVC requesting the default storage class. | ||
|
||
* During installation, the installer creates a PVC for the image registry, requesting the default storage class, which has not yet been created. | ||
|
||
In the preceding scenarios, the PVCs remain in pending state indefinitely. | ||
|
||
{product-title} provides a feature to retroactively assign the default storage class to PVCs, so that they do not remain in the pending state. With this feature enabled, PVCs requesting the default storage class that are created when no default storage classes exists, remain in the pending state until a default storage class is created, or one of the existing storage classes is declared the default. As soon as the default storage class is created or declared, the PVC gets the new default storage class. | ||
|
||
:FeatureName: Retroactive default storage class assignment | ||
include::snippets/technology-preview.adoc[leveloffset=+1] | ||
|
||
=== Procedure | ||
|
||
To enable retroactive default storage class assignment: | ||
|
||
. Enable feature gates (see _Nodes_ → _Working with clusters_ → _Enabling features using feature gates_). | ||
+ | ||
[IMPORTANT] | ||
==== | ||
After turning on Technology Preview features using feature gates, they cannot be turned off. As a result, cluster upgrades are prevented. | ||
==== | ||
+ | ||
The following configuration example enables retroactive default storage class assignment, and all other Technology Preview features: | ||
+ | ||
[source, yaml] | ||
---- | ||
apiVersion: config.openshift.io/v1 | ||
kind: FeatureGate | ||
metadata: | ||
name: cluster | ||
spec: | ||
featureSet: TechPreviewNoUpgrade <1> | ||
... | ||
---- | ||
<1> Enables retroactive default storage class assignment. | ||
|