Re: libvirt uninstallable (was: Re: Improving Fedora boot time when libvirt is installed)
On Mon, Feb 06, 2023 at 07:56:50AM -0800, Gordon Messmer wrote: > On 2023-02-06 07:27, Richard W.M. Jones wrote: > > Why was this line added? > > > > + Requires: (fedora-release > 38-0.23 if fedora-release) > > > > I suppose it's related to this change in fedora-release: > > > > https://src.fedoraproject.org/rpms/fedora-release/c/096fc7da49de5655db7aad17057e32191f2afe59?branch=rawhide > > > Yes. > > > > Did you mean >= in the conditional? > > > Also yes. > > https://src.fedoraproject.org/rpms/iscsi-initiator-utils/pull-request/11 My bad. I suggested '>'. Usually this would work because there'd be a dist tag, but fedora-release doesn't have the dist tag. There's another issue: the dependency should be on fedora-release-common instead -> https://src.fedoraproject.org/rpms/iscsi-initiator-utils/pull-request/12. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libvirt uninstallable (was: Re: Improving Fedora boot time when libvirt is installed)
On 2023-02-06 07:27, Richard W.M. Jones wrote: Why was this line added? + Requires: (fedora-release > 38-0.23 if fedora-release) I suppose it's related to this change in fedora-release: https://src.fedoraproject.org/rpms/fedora-release/c/096fc7da49de5655db7aad17057e32191f2afe59?branch=rawhide Yes. Did you mean >= in the conditional? Also yes. https://src.fedoraproject.org/rpms/iscsi-initiator-utils/pull-request/11 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
libvirt uninstallable (was: Re: Improving Fedora boot time when libvirt is installed)
So I think related to this thread, libvirt is now uninstallable in Rawhide: DEBUG util.py:443: Error: DEBUG util.py:443: Problem: problem with installed package fedora-release-38-0.23.noarch DEBUG util.py:443:- package iscsi-initiator-utils-6.2.1.4-8.git2a8f9d8.fc38.x86_64 requires (fedora-release > 38-0.23 if fedora-release), but none of the providers can be installed DEBUG util.py:443:- package libvirt-daemon-driver-storage-iscsi-9.0.0-2.fc38.x86_64 requires iscsi-initiator-utils, but none of the providers can be installed DEBUG util.py:443:- package libvirt-daemon-driver-storage-9.0.0-2.fc38.x86_64 requires libvirt-daemon-driver-storage-iscsi = 9.0.0-2.fc38, but none of the providers can be installed DEBUG util.py:443:- package libvirt-daemon-kvm-9.0.0-2.fc38.x86_64 requires libvirt-daemon-driver-storage = 9.0.0-2.fc38, but none of the providers can be installed DEBUG util.py:443:- conflicting requests I don't really understand the change that led to this: https://src.fedoraproject.org/rpms/iscsi-initiator-utils/c/1e689cd0c6667eca838c85975a1b7a070209e5ad?branch=rawhide Why was this line added? + Requires: (fedora-release > 38-0.23 if fedora-release) I suppose it's related to this change in fedora-release: https://src.fedoraproject.org/rpms/fedora-release/c/096fc7da49de5655db7aad17057e32191f2afe59?branch=rawhide Did you mean >= in the conditional? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Sun, Jan 22, 2023 at 02:48:31PM -0800, Gordon Messmer wrote: > On 2023-01-22 14:35, Gordon Messmer wrote: > > What do I misunderstand about systemd presets? > > ... actually, the systemd presets look like they *don't* need to be > adjusted. I reverted the change I thought the presets needed, removed the > packages, reinstalled, and iscsi-starter ended up enabled. > > That doesn't mean I understand the presets arrangement, but... presets don't work for package upgrades where a new unit is added. 'systemctl preset' (or equivalent) is only called in two specific situations: - when a package is first installed - when we boot an unconfigured system (with empty /etc) for the first time In other cases, presets for a new unit need to be handled via %triggerun. I added a comment with some code in the pull request. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Fr, 20.01.23 14:04, Colin Walters (walt...@verbum.org) wrote: > > > On Thu, Jan 19, 2023, at 11:53 AM, Gordon Messmer wrote: > > On 2023-01-19 00:55, Lennart Poettering wrote: > >> > >> What you could do is split up the problem: have iscsi-starter.service > >> or so, that is separate from the iscsi.service main service. The > >> former's job would be to scan if iscsi volumes are configured. If it > >> finds configured ones, it would then issue "systemctl start --no-block > >> iscsi.service" to enqueue a start job for the real thing. > > > > > > Something like that was suggested last year, and Colin Walters objected, > > for what that's worth. > > > > If the PR to allow installing only the "core" storage drivers is > > rejected, then I'll work on a PR to implement this change instead. > > Heh well, I'm obviously going to defer to Lennart if he has an > opinion on how you should do something with systemd. Just to say this clearly: I am actually with Colin on this too: needlessly adding in dynamic transactions during boot is not a great approach generally, since it reduces what we can parallelize, and makes behaviour less predictable and efficeint. Thus, people should not use what I proposed as a model for anything. It's a passable solution to an immediate problem, not more. So, what should the actual model to follow be in my opinion? Well, iscsid should just arrive in 2023 and watch rtnetlink on its own, and not rely on any "wait-online" services to delay boot processes. It should start early, not delay anything and make iscsi block devices pop up locally the instant connectivity allows it. And it should watch connectivity on its own, and retry contacting its severs whenever a new local network interface pops up and gets configured. And vice versa: if connectivity is lost (and policy dictates) remove block devices again. Or in other words, its 2022, and hotplug hardware is a thing, since 25 years now. iscsi devices should really feel like any other hotplugged hw, and be robust to network configuration changes. In such a model, iscsid would be a daemon you could start at any time in the boot process, and it would just work and make the devices it is configured for popup the moment that's possible, without any external scheduling and very very robustly. I am aware though that storage folks are not typically on the forefront of how device management is supposed to work these days (we still have some storage stuff pulling in systemd-udev-settle.service, don't we?), so I have no illusion that iscsi maintainers would even accept existance of rtnetlink as a thing. Maybe 25y from now, we'll see movement on that. > It wouldn't even be the first thing calling `systemctl start` in the > boot process...sadly there's NetworkManager dispatcher scripts that > *also* `try-restart iscsid` =/ That's much worse actually, and just another artifact of the fact that iscsid is too dumb to just watch the network state on its own, the one major thing it really depends on. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On 2023-01-22 14:35, Gordon Messmer wrote: What do I misunderstand about systemd presets? ... actually, the systemd presets look like they *don't* need to be adjusted. I reverted the change I thought the presets needed, removed the packages, reinstalled, and iscsi-starter ended up enabled. That doesn't mean I understand the presets arrangement, but... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On 2023-01-22 10:14, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jan 19, 2023 at 01:48:16PM -0800, Gordon Messmer wrote: On 2023-01-19 00:55, Lennart Poettering wrote: hat you could do is split up the problem: have iscsi-starter.service or so, that is separate from the iscsi.service main service. I think this is the way to go. OK, I've created https://src.fedoraproject.org/rpms/iscsi-initiator-utils/pull-request/10 Locally, this seems to work as expected with one exception: I changed iscsi.service to iscsi-starter.service in 90-default.preset, but iscsi-starter.service isn't enabled unless I manually enable it. Once I do that, then I get a fast boot when /var/lib/iscsi/nodes is empty and slower when it is not. What do I misunderstand about systemd presets? I also notice some references in the iscsi-initiator-utils package to running in intrd, but I don't see anything relevant in dracut. So, some work remains, and I will submit more PRs if I figure out what's needed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
(replying here to avoid multiple emails) On Thu, Jan 19, 2023 at 01:48:16PM -0800, Gordon Messmer wrote: > On 2023-01-19 00:55, Lennart Poettering wrote: > > hat you could do is split up the problem: have iscsi-starter.service > > or so, that is separate from the iscsi.service main service. I think this is the way to go. Lennart's solution is elegant and simple. The unit *right now* has ConditionDirectoryNotEmpty, so it already is skipped if /var/lib/iscsi/nodes is empty, so this change seems pretty safe. It just moves the check to a better point in time. I think this approach is much better than just downgrading the package dependencies: - it immediately works for people who upgrade and already have the package installed without any local intervention. - it also works for people who legitimately need the iscsi package, so you avoid the effect where default installs are OK, but then the user installs a bunch of packages and the next reboot is painful. > If I'm not mistaken, this approach would also probably need approval by > FESCo, since it'd involve reverting the "default on" status of the iscsi > service. Is that right? Yes. But it'd be more of a rubber stamp. If you remove the dep on network-online.service, everybody will be happy. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Thu, Jan 19, 2023 at 2:32 PM Gordon Messmer wrote: > > On 2023-01-19 09:48, Daniel P. Berrangé wrote: > > The idea is that an application will put a dep on the > > specific libvirt-daemon-driver-XXX that its functionality > > requires. If Boxes requires storage APIs, then add a > > Requires: libvirt-daemon-driver-storage-core, along with > > any of the storage backends Boxes uses. > > > It looks like there are currently ~ 13 packages that currently require > libvirt or libvirt-daemon-kvm that would need review and possibly > adjustment, and I'm willing to do that work, but I have to ask: How > likely is it that "fedora-comps" would accept a PR that narrows the > libvirt package set in the "virtualization" and > "virtualization-headless" groups? This is unlikely to fly, because composition groups here are intended to help people get to those full setups. That said, I don't know of any variant using those composition groups for live media, so it shouldn't be a problem to leave them alone. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Thu, Jan 19, 2023 at 11:32:24AM -0800, Gordon Messmer wrote: > On 2023-01-19 09:48, Daniel P. Berrangé wrote: > > The idea is that an application will put a dep on the > > specific libvirt-daemon-driver-XXX that its functionality > > requires. If Boxes requires storage APIs, then add a > > Requires: libvirt-daemon-driver-storage-core, along with > > any of the storage backends Boxes uses. > > > It looks like there are currently ~ 13 packages that currently require > libvirt or libvirt-daemon-kvm that would need review and possibly > adjustment, and I'm willing to do that work, but I have to ask: How likely > is it that "fedora-comps" would accept a PR that narrows the libvirt package > set in the "virtualization" and "virtualization-headless" groups? I think that would be an acceptable PR personally. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Thu, Jan 19, 2023, at 11:53 AM, Gordon Messmer wrote: > On 2023-01-19 00:55, Lennart Poettering wrote: >> >> What you could do is split up the problem: have iscsi-starter.service >> or so, that is separate from the iscsi.service main service. The >> former's job would be to scan if iscsi volumes are configured. If it >> finds configured ones, it would then issue "systemctl start --no-block >> iscsi.service" to enqueue a start job for the real thing. > > > Something like that was suggested last year, and Colin Walters objected, > for what that's worth. > > If the PR to allow installing only the "core" storage drivers is > rejected, then I'll work on a PR to implement this change instead. Heh well, I'm obviously going to defer to Lennart if he has an opinion on how you should do something with systemd. It wouldn't even be the first thing calling `systemctl start` in the boot process...sadly there's NetworkManager dispatcher scripts that *also* `try-restart iscsid` =/ That said, I do think a general better pattern is to either: - Have the daemon itself run `systemctl enable` if it detects the scenario; though the problem with this is that if the daemon is removed, the enablement state will "leak", but a workaround for that is to ship a unit in your daemon which is itself conditionally enabled, and *that* unit has Wants/Requires=iscsid.service. So there'd be libvirt-iscsid-requirement.service or so. - Write a "stamp file" to /var/lib/mydaemon, then a generator can key off that. (Instead of e.g. starting up libvirt and parsing its whole database etc.) But this intersects with the /var requirement, unless you move it to /etc. (I had actually forgotten though that it's not guaranteed /var is mounted, I'm pretty sure we have some implicit requirements on that some places) This thread is really similar to https://github.com/containers/podman/pull/17110 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On 2023-01-19 00:55, Lennart Poettering wrote: hat you could do is split up the problem: have iscsi-starter.service or so, that is separate from the iscsi.service main service. If I'm not mistaken, this approach would also probably need approval by FESCo, since it'd involve reverting the "default on" status of the iscsi service. Is that right? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On 2023-01-19 09:48, Daniel P. Berrangé wrote: The idea is that an application will put a dep on the specific libvirt-daemon-driver-XXX that its functionality requires. If Boxes requires storage APIs, then add a Requires: libvirt-daemon-driver-storage-core, along with any of the storage backends Boxes uses. It looks like there are currently ~ 13 packages that currently require libvirt or libvirt-daemon-kvm that would need review and possibly adjustment, and I'm willing to do that work, but I have to ask: How likely is it that "fedora-comps" would accept a PR that narrows the libvirt package set in the "virtualization" and "virtualization-headless" groups? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Thu, Jan 19, 2023 at 09:40:24AM -0800, Gordon Messmer wrote: > On 2023-01-19 09:07, Daniel P. Berrange wrote: > > berrange commented on the pull-request: `Permit an installation of only > > core storage drivers.` that you are following: > > `` > > THis isn't really required. If someone wants to have a fully minimal > > install of QEMU/KVM, then install 'libvirt-daemon-driver-qemu', instead of > > 'libvirt-daemon-kvm' - the latter is the convenience intended to be fully > > featured. > > > > We've tried to describe the intended usage > > herehttps://libvirt.org/kbase/rpm-deployment.html#deployment-choices > > `` > > > > To reply, visit the link below > > https://src.fedoraproject.org/rpms/libvirt/pull-request/16 > > > At least gnome-boxes and the Virtualization group in comps.xml will pull in > libvirt-daemon-kvm. And installing libvirt-daemon-driver-qemu instead will > give users an installation without even libvirt-daemon-driver-storage-core, > which seems... not great. The idea is that an application will put a dep on the specific libvirt-daemon-driver-XXX that its functionality requires. If Boxes requires storage APIs, then add a Requires: libvirt-daemon-driver-storage-core, along with any of the storage backends Boxes uses. 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On 2023-01-19 09:07, Daniel P. Berrange wrote: berrange commented on the pull-request: `Permit an installation of only core storage drivers.` that you are following: `` THis isn't really required. If someone wants to have a fully minimal install of QEMU/KVM, then install 'libvirt-daemon-driver-qemu', instead of 'libvirt-daemon-kvm' - the latter is the convenience intended to be fully featured. We've tried to describe the intended usage herehttps://libvirt.org/kbase/rpm-deployment.html#deployment-choices `` To reply, visit the link below https://src.fedoraproject.org/rpms/libvirt/pull-request/16 At least gnome-boxes and the Virtualization group in comps.xml will pull in libvirt-daemon-kvm. And installing libvirt-daemon-driver-qemu instead will give users an installation without even libvirt-daemon-driver-storage-core, which seems... not great. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On 2023-01-19 09:07, Daniel P. Berrange wrote: berrange commented on the pull-request: `Permit an installation of only core storage drivers.` that you are following: `` THis isn't really required. If someone wants to have a fully minimal install of QEMU/KVM, then install 'libvirt-daemon-driver-qemu', instead of 'libvirt-daemon-kvm' - the latter is the convenience intended to be fully featured. We've tried to describe the intended usage herehttps://libvirt.org/kbase/rpm-deployment.html#deployment-choices `` To reply, visit the link below https://src.fedoraproject.org/rpms/libvirt/pull-request/16 At least gnome-boxes and the Virtualization group in comps.xml will pull in libvirt-daemon-kvm. And installing libvirt-daemon-driver-qemu instead will give users an installation without even libvirt-daemon-driver-storage-core, which seems... not great. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On 2023-01-19 08:57, Lennart Poettering wrote: On Do, 19.01.23 08:53, Gordon Messmer (gordon.mess...@gmail.com) wrote: Something like that was suggested last year, and Colin Walters objected, for what that's worth. have a link? Last year's thread is here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/HACVEJ3FMOIM2TOENOVH5CPOUNR7NCMS/#5LTJ237DIWDRQFYPROAM5S3HJFFZC6YR ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Do, 19.01.23 08:53, Gordon Messmer (gordon.mess...@gmail.com) wrote: > On 2023-01-19 00:55, Lennart Poettering wrote: > > > > What you could do is split up the problem: have iscsi-starter.service > > or so, that is separate from the iscsi.service main service. The > > former's job would be to scan if iscsi volumes are configured. If it > > finds configured ones, it would then issue "systemctl start --no-block > > iscsi.service" to enqueue a start job for the real thing. > > Something like that was suggested last year, and Colin Walters objected, for > what that's worth. have a link? Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On 2023-01-19 00:55, Lennart Poettering wrote: What you could do is split up the problem: have iscsi-starter.service or so, that is separate from the iscsi.service main service. The former's job would be to scan if iscsi volumes are configured. If it finds configured ones, it would then issue "systemctl start --no-block iscsi.service" to enqueue a start job for the real thing. Something like that was suggested last year, and Colin Walters objected, for what that's worth. If the PR to allow installing only the "core" storage drivers is rejected, then I'll work on a PR to implement this change instead. Thanks, Lennart. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On 2023-01-19 01:25, Daniel P. Berrangé wrote: 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. That sounds like a good plan. Would you consider https://src.fedoraproject.org/rpms/libvirt/pull-request/16 ? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:
Re: Improving Fedora boot time when libvirt is installed
On Mi, 18.01.23 10:19, Gordon Messmer (gordon.mess...@gmail.com) wrote: > 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. So yeah, this is a mess, indeed. We have been thinking in systemd if we shouldn't tighten the requirements a bit and dictate that in future /var/ has to be mounted at the moment of the initrd → host transition. That would make the problem go away. We currently require that the root fs and /usr/ are already mounted during the transition. It's not *that* much more to require /var/, too. But I guess that is more a long term thing. What you could do is split up the problem: have iscsi-starter.service or so, that is separate from the iscsi.service main service. The former's job would be to scan if iscsi volumes are configured. If it finds configured ones, it would then issue "systemctl start --no-block iscsi.service" to enqueue a start job for the real thing. Then, the starter unit would not be ordered after the wait-online service, but the real iscsi one would be. Finally, iscsi.service's [Install] section would not carry any WantedBy= lines or so, i.e. would not hook itself into anything if enabled. Instead it would only carry Also=iscsi-starter.service there, which would basically "redirect" enablement to the starter service. And the starter service would then do WantedBy=sysinit.target to hook itself into the early boot. Both services would use DefaultDependencies=no, and the starter service would use RequiresMountsFor=/var/lib/iscsi/nodes so that it waits exactly until its /var/ dir is up, but not more. The starter service could probably look roughly like this btw: [Unit] DefaultDependencies=no Before=sysinit.target iscsi.service RequiresMountsFor=/var/lib/iscsi/nodes ConditionDirectoryNotEmpty=/var/lib/iscsi/nodes [Service] Type=oneshot RemainAfterExit=true ExecStart=/usr/bin/systemctl start --no-block --job-mode=fail iscsi.service Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Wed, Jan 18 2023 at 08:27:02 PM +0100, Fabio Valentini wrote: Suggests are useful for the case where multiple packages (let's say packages A and B) provide "foo", a package C depends on something that provides "foo" (i.e. works with both A and B), but C prefers A over B if neither of them are installed yet. Very interesting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On 2023-01-18 11:20, Michael Catanzaro wrote: 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. No, Suggests basically does nothing. In case "Suggests" is an acceptable option, I've opened: https://src.fedoraproject.org/rpms/libvirt/pull-request/15 I've built a package with that change, locally, and verified that I can remove the iscsi utils. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On 2023-01-18 11:20, Michael Catanzaro wrote: No, Suggests basically does nothing. See this table here: https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/ Recommends and Supplements are real dependencies that are installed automatically but which you can opt out of. Suggests and Enhances are just kinda there, and will not be installed automatically. Not sure if they are really useful. My mistake. Thanks for the correction! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Wed, Jan 18, 2023 at 8:20 PM Michael Catanzaro wrote: > > On Wed, Jan 18 2023 at 10:19:24 AM -0800, Gordon Messmer > wrote: > > 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. > > No, Suggests basically does nothing. See this table here: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/ > > Recommends and Supplements are real dependencies that are installed > automatically but which you can opt out of. Suggests and Enhances are > just kinda there, and will not be installed automatically. Not sure if > they are really useful. Suggests are useful for the case where multiple packages (let's say packages A and B) provide "foo", a package C depends on something that provides "foo" (i.e. works with both A and B), but C prefers A over B if neither of them are installed yet. Then package C can add "Suggests: B" to make dependency resolution preferentially resolve "Requires: foo" to B. Otherwise, dependency resolution apparently prefers packages that sort lower alphabetically (so A instead of B, in this simplified example). Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Wed, Jan 18 2023 at 10:19:24 AM -0800, Gordon Messmer wrote: 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. No, Suggests basically does nothing. See this table here: https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/ Recommends and Supplements are real dependencies that are installed automatically but which you can opt out of. Suggests and Enhances are just kinda there, and will not be installed automatically. Not sure if they are really useful. 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) This sounds attractive too. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
