Uploaded image for project: 'OpenShift Storage'
  1. OpenShift Storage
  2. STOR-545

Allow users creation of more than one default storage class [GA]

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Normal Normal
    • openshift-4.13
    • None
    • Allow users creation of more than one default storage class
    • Upstream
    • 0
    • False
    • False
    • Storage
    • To Do
    • OCPSTRAT-158 - Default Storage Class Management
    • OCPSTRAT-158Default Storage Class Management
    • 0% To Do, 0% In Progress, 100% Done
    • Undefined

      Epic Goal

      • This Epic has been moved over from a bug (as this is RFE work):

      Description of problem:

      User can create more than one default storage class and when he creates pvc without define sc he got error: Internal error occurred: 4 default StorageClasses were found

      Expected results:
      it should not be possible to create more than one default storage class

      We're going to solve it this way: OCP will allow users to create two or more default storage classes. One of them will then be used for PVCs, without throwing any error. We should document which SC is used (it's deterministic in the code).

      In addition, we already added an alert that there are more default StorageClasses.

      This is already implemented upstream in 1.26: https://github.com/kubernetes/kubernetes/pull/110559. There is no feature gate, it's GA.

      Why is this important?

      • Some customers would like to create more than one storage class
      • Now that we have validating webhooks we are able to implement a stable solution

      Scenarios

      1. Create a default storage class A
      2. Create a default storage class B
      3. Create PVC with pvc.spec.storageCLassName = nil

      -> the PVC will get the default storage class with the newest CreationTimestamp (i.e. B) and no error should show.

      -> admin will get an alert that there are multiple default storage classes and they should do something about it.

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      Open questions::

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

              rhn-engineering-jsafrane Jan Safranek
              rhn-support-dhardie Duncan Hardie
              Rohit Patil Rohit Patil
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: