On Wed, Jan 18, 2023 at 10:19:24AM -0800, Gordon Messmer wrote: > (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) The libvirt packaging is already modular. The 'libvirt-daemon-driver-storage' package is intended to bring in /all/ storage backends libvirt supports. To avoid that, it is possible to depend on 'libvirt-daemon-drive-storage-core' instead which pulls in only storage backends which have no extra deps. Removing or weakening the dep on libvirt-daemon-driver-storage-iscsi from libvirt-daemon-driver-storage, would undermine the point of this wrapper package which is intended to provide apps with all storage features, so this is not something we would like to do. > 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) With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
