Description of problem - Provide a detailed description of the issue encountered, including logs/command-output snippets and screenshots if the issue is observed in the UI:

Specified volume selector via groups  of 'type: volume' and included group in the backup / restore workflows as shown below : 

groups:
  - name: captured-volumes
     type: volume
     includedNamespaces:
      - $ALL_NAMESPACES
      labelSelector:
        matchExpressions:
        - key: ramendr.openshift.io/exclude
          operator: NotIn
          values:
          - "true"
{}...
 workflows:
  - failOn: any-error
    name: backup
    sequence:
    - group: captured-volumes
    - ..
  - failOn: any-error
    name: restore
    sequence:
    - group: captured-volumes
    - ...

This failed (in scenarios where velero annotations were present & resources unhealthy), but specifying same selection via volumes object was successful.  

volumes:
   includedNamespaces:
   - $ALL_NAMESPACES
   labelSelector:
     matchExpressions:
     - key: app.kubernetes.io/name
       operator: In
       values:
       - filebrowser-rbd
   name: captured-volumes
   type: volume

The OCP platform infrastructure and deployment type (AWS, Bare Metal, VMware, etc. Please clarify if it is platform agnostic deployment), (IPI/UPI):
Bare Metal - IPI

The ODF deployment type (Internal, External, Internal-Attached (LSO), Multicluster, DR, Provider, etc):

Internal-Attached (LSO)

The version of all relevant components (OCP, ODF, RHCS, ACM whichever is applicable):

OCP 4.17.3
ODF 4.17.1
ACM 2.12.1

Does this issue impact your ability to continue to work with the product?

yes to degree - alternatives for volume specification documented do not work the same, inconsistent results based on workload usage of velero hooks

Is there any workaround available to the best of your knowledge?

use volume object

Can this issue be reproduced? If so, please provide the hit rate

yes  

Can this issue be reproduced from the UI? yes

If this is a regression, please provide more details to justify this:

Steps to Reproduce:

1. Install application w/ velero annotations

2. Setup DR protection for application - include recipe using groups of type volume

3. relocate application 

The exact date and time when the issue was observed, including timezone details:

Dec 2nd

Actual results:

Specifying volumes capture information behaved differently across the documented alternatives  - groups with type of volume & volume object{}

Expected results:

Specifying volumes capture information behaves same across the documented alternatives - groups with type of volume & volume object

Logs collected and log location:

Additional info: