Improving Fedora boot time when libvirt is installed

(apologies for the long-ish message, but I'd like to save people the trouble of re-reading a year-old very long email thread) Early last year there was a thread on this list (Re: "Is NetworkManager-wait-online.service necessary by default?") in which maintainers discussed the issue of boot times increasing when libvirt was installed as a result of iscsi creating a service order dependency between network-online and remote-fs-pre.  If I'm not mistaken, it was unanimously agreed that it was undesirable for this dependency to exist. This delay is still the most common cause that I find among people who complain that it takes a long time to boot Fedora, and unfortunately the most common advice given to those people is "disable network-online".  It's difficult to explain why this is a Bad Thing (TM). A number of possible solutions were discussed in that thread. Unfortunately many of them don't work (or don't work reliably), which I assume is why the problem is not solved, so I'm hoping to revive discussion of the ones that will work.  The problem occurs because: 1) libvirt requires libvirt-daemon-driver-storage-iscsi and iscsi-initiator-utils, 2) iscsi.service is enabled by default (per https://pagure.io/fesco/issue/2386), 3) iscsi.service is ordered after network-online and 4) before remote-fs-pre.target. iscsi.service already has a "ConditionDirectoryNotEmpty", but that's evaluated when the service would be executed, so the ordering dependency between network-online and remote-fs-pre exists even though iscsi won't start.  There was some discussion of using ".path" units, but that seems to have the same problem. There was also discussion of disabling the service by default and using a generator to enable the service, and Lennart thought this was the best solution.  I started work to add a simple generator, but the documentation for systemd.generator states "Non-essential file systems like /var/ and /home/ are mounted after generators have run," and the purpose of the generator would be to enable the service when there are files in /var/lib/iscsi/nodes. Several people suggested using a weak dependency (Suggests:) on the iscsi driver, but I don't think that would solve the problem for most users because weak dependencies are installed by default and nothing really communicates to users that unless they add an obscure option, their boot times will increase. So, things that could work: The package dependency could be dropped from libvirt entirely. Libvirt users who want iscsi support can install that storage driver manually. (addressing condition 1) A generator would work if the iscsi node configs were in /etc instead of /var.  Would we consider changing the package layout? Possibly, moving the node configurations to /etc and changing /var/lib/iscsi/nodes to a symlink, with a pre-install script to handle existing installations?  We'd also need to change the default service state to disabled. (addressing condition 2) The ordering dependency on remote-fs-pre.target could be dropped, though I expect that there will be objections and that option wouldn't be considered. (addressing condition 4) FESCo could also revisit 2386 and reconsider whether enabled by default is the right decision for this service.  I assume there was an explicit decision for this because of the policy that an enabled-by-default service "must not require manual configuration to function", which iscsi does.  Maybe the fact that it requires manual configuration means that interested users should also be required to enable the service, given the pain that the status quo causes for what seems like the far more common case that this service is installed by all users of libvirt but not needed by most of them. (also addressing condition 2)