Uploaded image for project: 'OpenShift Virtualization'
  1. OpenShift Virtualization
  2. CNV-72238

Introduce new scratch space SC selection logic

XMLWordPrintable

    • scratch-space-sc-logic-phase-1
    • 77
    • Hide
      • CDI has a new FG that enables same-as-target scratch space storage class selection logic
      • FG is off by-default
      • HCO allows you to set this FG if desired
      • Docs updated to reflect this new option
      • Tests for the new logic in CDI
      Show
      CDI has a new FG that enables same-as-target scratch space storage class selection logic FG is off by-default HCO allows you to set this FG if desired Docs updated to reflect this new option Tests for the new logic in CDI
    • To Do

      Goal

      Introduce a new feature gate in CDI and HCO that enables the same-as-target scratch space selection logic. This feature gate will be off by-default for this release.

      User Stories

      • As a VM owner I want to use the same storage class for all provisioning of a particular disk (including scratch space). When I provision a disk on a non-default storage class I want to use that same storage class for scratch space (not the default storage class).

      Non-Requirements

      • List of things not included in this epic, to alleviate any doubt raised during the grooming process.

      Notes

      Certain CDI operations require a scratch space PVC. This PVC is automatically allocated by CDI when needed according to the following rules:

      • Use the storage class defined in the optional scratchSpaceStorageClass HCO config item
      • Use the virt-default storage class
      • Use the default storage class

      We want to switch to the following logic which aligns more closely with customer expectations:

      • Use the storage class defined in the optional scratchSpaceStorageClass HCO config item
      • Use the same storage class as the target PVC

      We are completing this change in semantics over three steps in order to ensure that there are no disruptions:
      1. Introduce a new FG (off by-default) that enables the new behavior.
      2. Turn the FG on by-default so the new behavior is default but can be disabled.
      3. Remove the FG to keep only the new behavior.

          1.
          upstream roadmap issue Sub-task New Normal Unassigned
          2.
          upstream design Sub-task New Normal Unassigned
          3.
          upstream documentation Sub-task New Normal Unassigned
          4.
          upgrade consideration Sub-task New Normal Unassigned
          5.
          test plans in polarion Sub-task New Normal Unassigned
          6.
          automated tests Sub-task New Normal Unassigned
          7.
          downstream documentation merged Sub-task New Normal Unassigned

              alitke@redhat.com Adam Litke
              alitke@redhat.com Adam Litke
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: