Il giorno mer 30 gen 2019 alle ore 21:39 Nir Soffer <nsoffer@redhat.com> ha scritto:
Last time we discussed this here, we had only sanlock issue:

The bug was fixed upstream about 2 month ago, but the Fedora package was not available.

The package is not available yet in Fedora, but we have a build here:

Reviewing it on https://bodhi.fedoraproject.org/updates/FEDORA-2019-ea4ecdc166
I see takotron found 6 issues with automated testing:
there's a comment in spec file containing a macro: # %patch0 -p1 -b .0001-foo.patch
which may cause unexpected behavior and should either be escaped (%%patch)  or dropped.

Also:
rpmlint FAILED for sanlock-3.6.0-4.fc28 (x86_64, noarch, src): 6 errors, 9 warnings

##### SRPMs #####
sanlock.src: E: description-line-too-long C The sanlock daemon manages leases for applications on hosts using shared storage.
sanlock.src:40: W: macro-in-comment %patch0
sanlock.src:81: W: mixed-use-of-spaces-and-tabs (spaces: line 7, tab: line 81)
1 packages and 0 specfiles checked; 1 errors, 2 warnings.

##### RPMs  #####
python2-sanlock.x86_64: W: no-documentation
sanlk-reset.x86_64: W: spelling-error %description -l en_US lockspace -> lock space, lock-space, locks pace
sanlk-reset.x86_64: E: dir-or-file-in-var-run /var/run/sanlk-resetd
sanlk-reset.x86_64: E: non-standard-dir-perm /var/run/sanlk-resetd 775
sanlock.x86_64: E: description-line-too-long C The sanlock daemon manages leases for applications on hosts using shared storage.
sanlock.x86_64: W: manual-page-warning /usr/share/man/man8/sanlock.8.gz 535: warning: macro `/"' not defined
sanlock.x86_64: E: dir-or-file-in-var-run /var/run/sanlock
sanlock.x86_64: E: non-standard-dir-perm /var/run/sanlock 775
sanlock.x86_64: W: empty-%postun
sanlock-devel.x86_64: W: no-dependency-on sanlock/sanlock-libs/libsanlock
sanlock-devel.x86_64: W: no-documentation
sanlock-lib.x86_64: W: no-documentation
5 packages and 0 specfiles checked; 5 errors, 7 warnings.

RPMs tested:
python2-sanlock-3.6.0-4.fc28.x86_64.rpm
sanlk-reset-3.6.0-4.fc28.x86_64.rpm
sanlock-3.6.0-4.fc28.src.rpm
sanlock-3.6.0-4.fc28.x86_64.rpm
sanlock-devel-3.6.0-4.fc28.x86_64.rpm
sanlock-lib-3.6.0-4.fc28.x86_64.rpm

If you want to whitelist some warnings/errors, see https://fedoraproject.org/wiki/Taskotron/Tasks/dist.rpmlint#whitelist


These RPMs use `python-` prefix without Python version in *Requires:

sanlock-3.6.0-4.fc28 BuildRequires:
 * python (python2 is available)
 * python-devel (python2-devel is available)

This is strongly discouraged and should be avoided. Please check
the required packages, and use names with either `python2-` or
`python3-` prefix.


Read the following document to find more information and a possible cause:
https://fedoraproject.org/wiki/Packaging:Python#Dependencies
Or ask at #fedora-python IRC channel for help.

If you think the result is false or intentional, file a bug against:
https://github.com/fedora-python/task-python-versions/issues

-----------

You've used /usr/bin/python during build on the following arches:

  sanlock-3.6.0-4.fc28: armv7hl, x86_64

Use /usr/bin/python3 or /usr/bin/python2 explicitly.
/usr/bin/python will be removed or switched to Python 3 in the future.

Grep the build.log for the following to find out where:

    DEPRECATION WARNING: python2 invoked with /usr/bin/python


Read the following document to find more information and a possible cause:
https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build
Or ask at #fedora-python IRC channel for help.

If you think the result is false or intentional, file a bug against:
https://github.com/fedora-python/task-python-versions/issues

-----------

 


You can install sanlock from this build using:


Hopefully the package will pushed soon to updates-testing repo.

With this you can use enable selinux as god intended.

But if you update your host to kernel 4.20.4-100, multipath is broken. All multipath devices
are not available, and your hosts will probably become non-operational since they report the 
iSCSI/FC storage domains in problem.

The issue was reported here:

And we have this Fedora 29 bug:

Ben explains it is:

The kernel is switching over to use block multiqueue instead of the old request
queue. Part of doing this is removing support for the old request queue
from device-mapper.  Another part is to remove support for the old
request queue from the scsi layer. For some reason, the first part got
into this fedora kernel, but the second part didn't.  It seems to me
that since the fedora kernel has removed support for non-blk-mq based devices, 
I should have been compiled with CONFIG_SCSI_MQ_DEFAULT=y

To fix this issue you need to add the scsi_mod.use_blk_mq=Y option to the kernel command line:

    grubby --args=scsi_mod.use_blk_mq=Y --update-kernel /boot/vmlinuz-4.20.4-100.fc28.x86_64

After reboot, your multipath devices will appear again.

Cheers,
Nir


--

SANDRO BONAZZOLA

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA

sbonazzo@redhat.com