Uploaded image for project: 'OpenShift API for Data Protection'
  1. OpenShift API for Data Protection
  2. OADP-989

Data Mover could restore PVCs with mover pod in a different node to the workload pod causing issues for PVCs with ReadWriteOnce accessMode


    • Icon: Bug Bug
    • Resolution: Not a Bug
    • Icon: Critical Critical
    • OADP 1.2.2
    • OADP 1.1.0
    • data-mover
    • 0
    • 0
    • Very Likely
    • 0
    • None
    • Unset
    • Unknown

      it is possible that a volume restored had its data written to by volsync via a different node than the in node the restore workload pod ended up scheduled to.

      If accessMode of PVC is ReadWriteOnce then it can cause data path read access issues.

      the volume can be mounted as read-write by a single node. ReadWriteOnce access mode still can allow multiple pods to access the volume when the pods are running on the same node.


      Fix strategies (pick one?):

      • Use ReadWriteMany when building replicationDestionation blocked by OADP-988
        • Need to document this so users are aware.
      • Prioritize pod restore before pvc so volsync AffinityFromVolume can work
        • we may need some kind of pre-hook or to modify workload pod's container to wait for direct copy to finish before starting workload.
      • Set pod affinity on restored pod if it had volumes moved by data mover so it gets restored to the same node that volsync pod used to write data to the pvc.

      I have a feeling this is blocking OADP-844


      Issue for making restored PVC have the same access mode as backup is broken into issue OADP-988.

      This issue only cover making RWO PVCs work with intended workload.

            marnold@redhat.com Matthew Arnold
            tkaovila@redhat.com Tiger Kaovilai
            Amos Mastbaum Amos Mastbaum
            0 Vote for this issue
            3 Start watching this issue