fix: do not filter out removable devices

[leelavg]

• hot pluggable devices are represented as removable in lsblk o/p
• not all removable devices should be filtered out and this PR removes
  the existing filter
• as a side effect ROM is being picked up for VG ops and that is
  filtered based on Type of device

fixes: #109

Signed-off-by: Leela Venkaiah G [email protected]

[leelavg]

• filtering out ROM device

{"level":"info","ts":1649414296.9406986,"logger":"controller.lvmvolumegroup.vg-manager","msg":"does not match filter","reconciler group":"lvm.topolvm.io","reconciler kind":"LVMVolumeGroup","name":"vg1","namespace":"lvm-operator-system","Device.Name":"sr0","filter.Name":"isUsableByDeviceType"}

• no regression

{"level":"info","ts":1649415065.6944656,"logger":"controller.lvmvolumegroup.vg-manager","msg":"does not match filter","reconciler group":"lvm.topolvm.io","reconciler kind":"LVMVolumeGroup","name":"vg1","namespace":"lvm-operator-system","Device.Name":"loop4","filter.Name":"isUsableByDeviceType"}

[nbalacha]

If, in future, there is a requirement to be able to configure the VG to not use loop devices , how would this be implemented?

Would it better to have one filter per type and add them to the list of filters for a VG dynamically depending on the configuration?

[leelavg]

how would this be implemented?

• then it'll be a straightforward implementation, we use all the strings based on device types in single case of switch and will filter them out
• it basically boils out to filtering out devices based on device types currently loop is a special case

Would it better to have one filter per type

• I feel adding filters per type will be too verbose and only increases filter count

[sp98]

how would this be implemented?

• then it'll be a straightforward implementation, we use all the strings based on device types in single case of switch and will filter them out
• it basically boils out to filtering out devices based on device types currently loop is a special case

Would it better to have one filter per type

• I feel adding filters per type will be too verbose and only increases filter count

Agree with Leela here. I don't think we need multiple filters for each device class. The current switch case usage would suffice.

[nbalacha]

how would this be implemented?

• then it'll be a straightforward implementation, we use all the strings based on device types in single case of switch and will filter them out
• it basically boils out to filtering out devices based on device types currently loop is a special case

Can you elaborate on this seeing that the supported types would be dynamic?

Would it better to have one filter per type

• I feel adding filters per type will be too verbose and only increases filter count

[nbalacha]

how would this be implemented?

• then it'll be a straightforward implementation, we use all the strings based on device types in single case of switch and will filter them out
• it basically boils out to filtering out devices based on device types currently loop is a special case

Would it better to have one filter per type

• I feel adding filters per type will be too verbose and only increases filter count

Agree with Leela here. I don't think we need multiple filters for each device class. The current switch case usage would suffice.

If, in future, we want to allow dynamic device type config, the switch case will not work. Say we want to use loopDevices for one cluster and not the other, we need a way to dynamically determine the filters.

[nbalacha]

Approving for now but we should relook at the filter approach.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: leelavg, nbalacha, sp98

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [nbalacha]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[nbalacha]

/cherry-pick release-4.10

[openshift-cherrypick-robot]

@nbalacha: new pull request created: #193

In response to this:

/cherry-pick release-4.10

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.