Volume leak test affected by side-effect lvs WARNING text

[okartau]

Recently added volume leak test gets false positive result
if a WARNING is reported by lvs command

same volumes before and after the test
Expected
   <map[string][]string | len:3>: {
      "LVM Volumes on Node 1": [""],
      "LVM Volumes on Node 2": [""],
      "LVM Volumes on Node 3": [""],
  }
to equal
   <map[string][]string | len:3>: {
       "LVM Volumes on Node 1": [""],
       "LVM Volumes on Node 2": [""],
       "LVM Volumes on Node 3": [
           "WARNING: Failed to connect to lvmetad. Falling back to device scanning.",
       ],
   }

[okartau]

--quiet option to lvs is documented to "Suppress output and log messages."
It is however not so sure it suppresses that warning.
I recall from some earlier cases about parsing LV commands output that error messages were not silenced by --quiet.
More strong method is to filter all lines containing "WARNING:"

[okartau]

Thanks @avalluri for pointing out method to leave out lvmetad: (copied from comment under #461)

We need to disable lvmetad checking on VM hosts as we did in our docker images:

RUN echo "global { use_lvmetad = 0 }" >> /etc/lvm/lvm.conf && \
    echo "activation { udev_sync = 0 udev_rules = 0 }" >> /etc/lvm/lvm.conf

[okartau]

I tried this method but it's not working universally. On a Ubuntu-based VM, when these lines are added to end of (already existing and quite long) /etc/lvm/lvm.conf,
then the values will conflict with existing values and result will be:

root@pmem-csi-ubuntu-govm-worker2:~# lvs
WARNING: Ignoring duplicate config value: use_lvmetad
WARNING: Ignoring duplicate config value: udev_sync
WARNING: Ignoring duplicate config value: udev_rules

When I add those lines at the end of
/etc/lvm/lvmlocal.conf instead (which is short file are meant to override existing values)
then there is no error.
Does it make sense to use lvmlocal.conf always?

[pohly]

Olev Kartau <notifications@github.com> writes:

When I add those lines at the end of `/etc/lvm/lvmlocal.conf` instead (which is short file are meant to override existing values) then there is no error. Does it make sense to use lvmlocal.conf always?

Yes, but only if that also works on Fedora and Clear.

[okartau]

interesting: after I create Clear-based test cluster using make start and fixed clear version 31070,
(BTW should I switch to newer Clear version already? 31070 was "good known to work" some times back) I see no lvmetad running and all lv-commands produce
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
That may mean all lvs commands have such output in CI and it gets compared and matches, so the end result is what we wanted, with an extra line compared (that seems escaped the testing).

Anyway, regardless of what we decide about running or blocking lvmetad, I propose:
Let's switch to exec.Output instead of exec.CombinedOutput:
That warning text is written to stderr, and we are only interested in stdout, and we dont plan
to parse whatever may be reported in stderr.
It is good enough for this test that cmd completed without error, and we can ignore the warnings in stderr
(which we would want to silence with -q option but the option does not affect that warning).

[pohly]

Olev Kartau <notifications@github.com> writes:

interesting: after I create Clear-based test cluster using `make start` and fixed clear version 31070, (BTW should I switch to newer Clear version already? 31070 was "good known to work" some times back)

Yes, we should update that more aggressively.

Anyway, regardless of what we decide about running or blocking lvmetad, I propose: Let's switch to exec.Output instead of exec.CombinedOutput:

Sounds like the right solution.