Stop trying to guess the name of the libvirt service/socket (fedora-35 necessary changes) #387
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
KKoukiou
force-pushed
the
no-detect-libvirt-socket
branch
from
69df1bb
to
d4f9985
Compare
KKoukiou
force-pushed
the
no-detect-libvirt-socket
branch
3 times, most recently
from
518f650
to
7d88784
Compare
KKoukiou
changed the title
KKoukiou
force-pushed
the
no-detect-libvirt-socket
branch
3 times, most recently
from
adf52f4
to
7e4c94e
Compare
1 task
|
/packit build |
martinpitt
requested changes
Sep 22, 2021
|
Still lots of failures on fedora-35, capturing log URL. Looks like you need to start some libvirt-network service as well perhaps? |
KKoukiou
force-pushed
the
no-detect-libvirt-socket
branch
5 times, most recently
from
fc422e4
to
a83dc18
Compare
And leave the service activation to libvirt itself. In all our supported distros the libvirt service is socket activated. The socket is running by default, from the very first moment the user installs the package. A stopped libvirt socket means that the user manually changed the default state, and should be left alone to do so. In addition to that, the libvirt daemon changed recently to a modular achitecture, so instead of a single monolithic libvirtd daemon we now get one for each driver (domain, storage, network, interfaces etc). Some distros already opted in the new modular daemons, (see https://www.mail-archive.com/libvir-list@redhat.com/msg219931.html) but many keep using the old monolithic libvirtd daemon. As now we will have many sockets to check for their state, we decided to get rid of any libvirt service/socket name detection logic from cockpit-machines. This logic was previously used to detect if the service was running and if not we showed the user an empty state screen. That also helped us to listen to socket/service changes and update the UI accordingly. This commit replaces this logic will a simple API call in the initial render of this app which allows us to check if a connection type is available; if that fails for any of the system/session connections, that means that the libvirt service is not available for the connection. For the same reason of the name detection logic being problematic, let's stop providing to the cockpit-machines users the ability to start/enable the libvirt service/socket from the cockpit-machines UI directly. This now allows us to make cockpit-machines work on fedora-35.
…ardown Same as we do for libvirtd / virtqemud. We do remove state in /var/run, without restarting the services libvirt get's somehow confused. Starting is done automatically as these are socket activated.
KKoukiou
force-pushed
the
no-detect-libvirt-socket
branch
from
a83dc18
to
a023e71
Compare
martinpitt
approved these changes
Sep 22, 2021
martinpitt
requested changes
Sep 22, 2021
There was a problem hiding this comment.
fails all over on the testing farm: 😢
error: Failed to connect socket to '/var/run/libvirt/virtnetworkd-sock': No such file or directory
error: failed to get network 'default'
As packit/f35 currently succeeds, this is a regression I'm afraid.
KKoukiou
force-pushed
the
no-detect-libvirt-socket
branch
from
993880e
to
0642e99
Compare
martinpitt
approved these changes
Sep 22, 2021
martinpitt
requested changes
Sep 22, 2021
martinpitt
force-pushed
the
no-detect-libvirt-socket
branch
from
0642e99
to
c6e0f26
Compare
|
At least the failure looks different now.. |
KKoukiou
force-pushed
the
no-detect-libvirt-socket
branch
from
c6e0f26
to
70d5de8
Compare
… package installation
KKoukiou
force-pushed
the
no-detect-libvirt-socket
branch
from
70d5de8
to
d7d07f9
Compare
martinpitt
approved these changes
Sep 23, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
And leave the service activation to libvirt itself.
In all our supported distros the libvirt service is socket activated.
The socket is running by default, from the very first moment the user
installs the package. A stopped libvirt socket means that the user
manually changed the default state, and should be left alone to do so.
In addition to that, the libvirt daemon changed recently to a modular
achitecture, so instead of a single monolithic libvirtd daemon we now
get one for each driver (domain, storage, network, interfaces etc). Some distros already
opted in the new modular daemons, (see https://www.mail-archive.com/libvir-list@redhat.com/msg219931.html)
but many keep using the old monolithic libvirtd daemon.
As now we will have many sockets to check for their state, we decided to get
rid of any libvirt service/socket name detection logic from
cockpit-machines.
This logic was previously used to detect if the service was running
and if not we showed the user an empty state screen.
That also helped us to listen to socket/service changes and update
the UI accordingly.
This commit replaces this logic will a simple API call in the initial
render of this app which allows us to check if a connection type is
available; if that fails for any of the system/session connections, that means that the libvirt service is not available for the connection.
For the same reason of the name detection logic being problematic, let's
stop providing to the cockpit-machines users the ability to start/enable
the libvirt service/socket from the cockpit-machines UI directly.