Feature Overview (aka. Goal Summary)  

An elevator pitch (value statement) that describes the Feature in a clear, concise way.  Complete during New status.

Switch deviceSelector path logic from

all listed devices must be present, logical AND

to

at least one listed device must be present, logical OR

Goals (aka. expected user outcomes)

The observable functionality that the user now has as a result of receiving this feature. Complete during New status.

Requirements (aka. Acceptance Criteria):

Simplify LVMS deployement, esp. when multiple worker nodes are present. Currently it is AND - if any device path in the list does not exists, the whole scan is aborted with an error. 

The requirement is to switch the implementation to OR logic, i.e. try all in the list, and fail only if NO device does match. All devices that match on a specific node.

The devices that do not match are reported e.g. in the status: field as "missing / warning"

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

This is derived from customer feedback. Customer has multi node deployments and needs to create LVM Cluster with lots of various disks across nodes. Currently it is very difficualt to specify this. Are really simple solution would be to provide a single list of device IDs (/dev/disk/by-id/...), and no matter on which nodes the disks are actually installed, it would work. It's easy for the customer to come up with a list of all disk IDs. Its much harder to tracker where which disk has been installed.

Customer Considerations

This change is expected to have little impact on existing customers. Either they use NO deviceSelect at all, getting the "all available disks are used" logic wich is not affected by this change.

Or they do specify path, this change will make old configs which failed (e.g. a single path not existing) now work, which is good / intendended. As we check for empty disks, there is no risk of accidentally using a previously otherwise  used disk, accidentally destroying data.

Documentation Considerations

Documentation needs to be updated and explain the "OR" logic in the following sections:

• Creating Logical Volume Manager cluster
• [ LVM Storage reference YAML file|https://docs.openshift.com/container-platform/4.12/storage/persistent_storage/persistent_storage_local/persistent-storage-using-lvms.html#lvms-reference-file_logical-volume-manager-storage]

Interoperability Considerations

none