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

support Azure File snapshot feature (TechPreview)

XMLWordPrintable

    • support Azure File snapshot feature (TechPreview)
    • BU Product Work
    • 1
    • False
    • None
    • False
    • Green
    • To Do
    • OCPSTRAT-1617 - Azure File CSI snapshots(TechPreview)
    • OCPSTRAT-1617Azure File CSI snapshots(TechPreview)
    • 0% To Do, 0% In Progress, 100% Done

      Epic Goal*

      Add support for snapshots in Azure File.

       

      Why is this important? (mandatory)

      We should track upstream issues and ensure enablement in OpenShift. Snapshots are a standard feature of CSI and the reason we did not support it until now was lacking upstream support for snapshot restoration.

      Snapshot restore feature was added recently in upstream driver 1.30.3 which we rebased to in 4.17 - https://github.com/kubernetes-sigs/azurefile-csi-driver/pull/1904

      Furthermore we already included azcopy cli which is a depencency of cloning (and snapshots). Enabling snapshots in 4.17 is therefore just a matter of adding a sidecar, volumesnapshotclass and RBAC in csi-operator which is cheap compared to the gain.

      However, we've observed a few issues with cloning that might need further fixes to be able to graduate to GA and intend releasing the cloning feature as Tech Preview in 4.17 - since snapshots are implemented with azcopy too we expect similar issues and suggest releasing snapshot feature also as Tech Preview first in 4.17.

       
      Scenarios (mandatory) 

      Users should be able to create a snapshot and restore PVC from snapshots.

       
      Dependencies (internal and external) (mandatory)

      azcopy - already added in scope of cloning epic

      upstream driver support for snapshot restore - already added via 4.17 rebase

       

      Contributing Teams(and contacts) (mandatory) 

      Our expectation is that teams would modify the list below to fit the epic. Some epics may not need all the default groups but what is included here should accurately reflect who will be involved in delivering the epic.

      • Development - 
      • Documentation -
      • QE - 

      Acceptance Criteria (optional)

      Provide some (testable) examples of how we will know if we have achieved the epic goal.  

      Drawbacks or Risk (optional)

      Reasons we should consider NOT doing this such as: limited audience for the feature, feature will be superseded by other work that is planned, resulting feature will introduce substantial administrative complexity or user confusion, etc.

      Done - Checklist (mandatory)

      The following points apply to all epics and are what the OpenShift team believes are the minimum set of criteria that epics should meet for us to consider them potentially shippable. We request that epic owners modify this list to reflect the work to be completed in order to produce something that is potentially shippable.

      • CI Testing -  Basic e2e automationTests are merged and completing successfully
      • Documentation - Content development is complete.
      • QE - Test scenarios are written and executed successfully.
      • Technical Enablement - Slides are complete (if requested by PLM)
      • Engineering Stories Merged
      • All associated work items with the Epic are closed
      • Epic status should be “Release Pending” 

            rbednar@redhat.com Roman Bednar
            rbednar@redhat.com Roman Bednar
            Rahul Deore Rahul Deore
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - 3 weeks
                3w
                Remaining:
                0m
                Logged:
                Time Not Required
                Not Specified