fix(multipath): drop dependency on systemd-udev-settle.service

[jlebon]

Rawhide systemd warns about this now:

udevadm[445]: systemd-udev-settle.service is deprecated. Please fix
multipathd-configure.service, multipathd.service not to pull it in.

Similarly to #1552, we don't actually need that dependency anyway here.
multipathd-configure.service just outputs a file in /etc and shouldn't
need to probe devices, and multipathd itself by nature is designed to
handle dynamic udev changes.

So just drop it.

[jlebon]

/cc @bmarzins

I've tested this on Fedora CoreOS 34 on top of multipath.

[bmarzins]

Did you test this with a filesystem that is necessary for bootup on top of a multipath device? The main reason that multipath still depends on systemd-udev-settle.service has to do with transitioning out of the initramfs, and needing the path devices that it is currently using to have been re-dicovered before multipathd starts up again. You can see the multipath issue here: opensvc/multipath-tools#3 with a comment by @mwilck explaining the problem. But this issue doesn't apply to multipathd initially starting up in the initramfs. So, it needs proper testing to verify, but I don't see an issue with removing the udev-settle dependency here.

[mwilck]

I've mixed feelings about this. @bmarzins is right that the argument I made in opensvc/multipath-tools#3 only applies after initramfs processing is finished. OTOH, changing the boot ordering for multipath is risky; we have lots of evidence for that. Is it reasonable to do that just because of this questionable warning? Thorough testing on multipath-enabled systems would be a requirement IMO.

BTW if we change this, we might be better off starting multipathd before systemd-udev-trigger.service. That way it will not see any maps on startup, and add paths as they get discovered. This is how it works for iSCSI. IMO it would be more reasonable than starting it after trigger but before settle, IOW while udev is scanning devices.

[mwilck]

This change will cause multipathd startup to race with udev device probing. That's not healthy. If we must drop the dependency on systemd-udev-settle.service, we should change the After= dependency on systemd-udev-trigger.service to Before=.

[jlebon]

The test I did on FCOS 34 was with root on multipath, and it did work though it was a somewhat artificial set up using qemu-nbd and qemu-kvm. I'm not in a position to test this more extensively. We don't personally need this fixed immediately. Since it's already tracked upstream, let's close it.