12:19 p.m.
(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)
1:20 p.m.
On Wed, Jan 18 2023 at 10:19:24 AM -0800, Gordon Messmer
<gordon.messmer(a)gmail.com> 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
1:27 p.m.
On Wed, Jan 18, 2023 at 8:20 PM Michael Catanzaro <mcatanzaro(a)redhat.com> wrote:
On Wed, Jan 18 2023 at 10:19:24 AM -0800, Gordon Messmer
<gordon.messmer(a)gmail.com> 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
7:14 p.m.
On Wed, Jan 18 2023 at 08:27:02 PM +0100, Fabio Valentini
<decathorpe(a)gmail.com> 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.
1:47 p.m.
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!
2:35 p.m.
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.
2:55 a.m.
On Mi, 18.01.23 10:19, Gordon Messmer (gordon.messmer(a)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 *thaaaaat* 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:
<snip>
[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
</snip>
Lennart
--
Lennart Poettering, Berlin
10:53 a.m.
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.
10:57 a.m.
On Do, 19.01.23 08:53, Gordon Messmer (gordon.messmer(a)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
11:25 a.m.
On 2023-01-19 08:57, Lennart Poettering wrote:
On Do, 19.01.23 08:53, Gordon Messmer (gordon.messmer(a)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.o...
1:04 p.m.
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
3:46 a.m.
On Fr, 20.01.23 14:04, Colin Walters (walters(a)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
3:48 p.m.
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?
12:14 p.m.
(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
4:35 p.m.
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.
4:48 p.m.
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...
2:17 p.m.
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
3:25 a.m.
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 :|
10:48 a.m.
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 ?
11:37 a.m.
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.
11:40 a.m.
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.
11:48 a.m.
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 :|
1:32 p.m.
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?
1:48 p.m.
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
6:55 p.m.
On Thu, Jan 19, 2023 at 2:32 PM Gordon Messmer <gordon.messmer(a)gmail.com> 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!
9:27 a.m.
New subject: 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/1e689cd0c6667e...
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/096fc7da49de5655db7aa...
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
9:56 a.m.
New subject: 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/096fc7da49de5655db7aa...
Yes.
Did you mean >= in the conditional?
Also yes.
https://src.fedoraproject.org/rpms/iscsi-initiator-utils/pull-request/11
2:08 p.m.
New subject: 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/096fc7da49de5655db7aa...
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
445
days inactive
464
days old
27 comments
10 participants
participants (10)
-
Colin Walters -
Daniel P. Berrangé -
Fabio Valentini -
Gordon Messmer -
Kevin Fenzi -
Lennart Poettering -
Michael Catanzaro -
Neal Gompa -
Richard W.M. Jones -
Zbigniew Jędrzejewski-Szmek