XMLWordPrintable

    • Strategic Product Work
    • False
    • Hide

      None

      Show
      None
    • False
    • OCPSTRAT-1131MicroShift Enhancements 2024 for Industrial, Retail and Public Sector edge customers
    • 0% To Do, 0% In Progress, 100% Done
    • M
    • 0

      Feature Overview (aka. Goal Summary)  

      MicroShift has built in CSI and CSI Snapshot capabilities. For customers who do not need CSI, this should be made optional, so they can opt out to save on resource (CPU, RAM, DISK).

      Goals (aka. expected user outcomes)

      Give customers the choice to enable or disable CSI Support and CSI SnapShots with MicroShift. 

      Requirements (aka. Acceptance Criteria):

      1. Create a MicroShift configuration option to enable basic CSI support. When enabled, the necessary controllers are deployed upon next startup, and provisioning of PVC can be done using the standard k8s way, as supported by the current LVMS implementation used as CSI provider.
      2. Create a MicroShift configuration option to enable CSI Snapshot support. When enabled, the necessary controllers are deployed upon next startup, and snapshots of PVs can be created/restored using the standard k8s way, as supported by LVMS. Of course, CSI snapshot capabilitiy depends on basic CSI support.
      3. Customers building ostree images with embedded containers need to be able to determine / omit the needed container images. This could be done  by splitting the current `release-x86_64.json` that is provided by microshift-release-info package into 'release-microshift.json', 'release-microshift-csi.json" and 'release-microshift-csi-snapshot.json'

      Please note: a 'configuration option' could be an entry in the microshift configuration file, or it could be the optional rpm installation of additional packages (e.g. microshift-csi-lvms, microshift-csi-snapshots). How this is actually done is an implementation detail that has to be 

       

      Questions to Answer (Optional):

      1. How to implement this, e.g. using optional rpm packages, or config file options.
      2. What is the default? Enable or disabled? Changing to disabled is a breaking change to previous versions and would need to be called out in docs (e.g. release notes)
      3. How does this relate to the effort to make CSI pluggable (see background), e.g. to allow upstream community to plug in a different CSI driver, not supported by Red Hat. 

      Out of Scope

      1. Once activated, CSI/snapshots can not be de-activated and leads to undefined behaviour.  This needs to be documented. 

       

      Background

      This relates to the oldie but Goldie epic to make CSI pluggable and the feature to enhance community (see links)

       

      Customer Considerations

      None at the moment.

       

      Documentation Considerations

      1. The documentation has to be updated to explain how to add these capabilities.
      2. The documentation should mention the resource overhead is induced by activating  CSI and CSI snapshots (e.g. #cores, RAM, storage needed). 
      3. If the default is "no CSI support" (e.g. because the feature is implemented using optional rpm packages), this has to be highligted in the release notes that customers might need to update their image build procedures to include the necessary packages.

       

      Interoperability Considerations

      None

       

              dfroehli42rh Daniel Fröhlich
              dfroehli42rh Daniel Fröhlich
              John George John George
              Shauna Diaz Shauna Diaz
              Jeremy Peterson Jeremy Peterson
              Jon Cope Jon Cope
              Daniel Fröhlich Daniel Fröhlich
              Jon Thomas Jon Thomas
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: