On Thu, Oct 13, 2022 at 09:43:50AM +0200, Erik Skultety wrote:
On Mon, Oct 10, 2022 at 11:09:51AM +0100, Daniel P. Berrangé wrote:
> On Mon, Oct 10, 2022 at 11:46:43AM +0200, Peter Krempa wrote:
> > After addition of the new libvirt-client-qemu sub-package which is using
> > python bindings (thus creating a circular dependency between the libvirt
> > and libvirt-python projects) the integration jobs fail with:
> >
> > Error:
> > Problem: conflicting requests
> > - nothing provides python3-libvirt >= 8.9.0-1.el9 needed by
libvirt-client-qemu-8.9.0-1.el9.x86_64
>
> Hmm, I wonder, should we really be trying to install *all* RPMs ?
>
> IIUC, we're only running integration tests for QEMU, so it ought
> to be sufficient to do only have the QEMU driver and virsh client
> and Perl APIs. eg can we change ci/integrate-templates.yml to
> do
>
> createrepo libvirt-rpms
> createrepo libvirt-perl
> dnf install libvirt-daemon-qemu libvirt-client perl-Sys-Virt
Sorry for the delay, I was actually integrating ^this suggestion and GitLab is,
well, slow to test these changes with. Anyhow, I vote for Peter's original
patch as it's the simplest and cleanest way to fix the problem, why? Here's
what I ended up with on my branch:
diff --git a/ci/integration-template.yml b/ci/integration-template.yml
index d4799b2ca8..9c58a1b71c 100644
--- a/ci/integration-template.yml
+++ b/ci/integration-template.yml
@@ -25,7 +25,31 @@
.install-deps: &install-deps
- - sudo dnf install -y libvirt-rpms/* libvirt-perl-rpms/*
+ - sudo dnf install -y createrepo
+ - createrepo libvirt-rpms
+ - createrepo libvirt-perl-rpms
+ - |-
+ for repo in libvirt-rpms libvirt-perl-rpms; do
+ cat << EOF >> "$SCRATCH_DIR/ci.repo"
+ [CI-$repo]
+ name=ci-$repo
+ baseurl=file://$(pwd)/$repo
+ enabled=1
+ gpgcheck=0
+ EOF
+ done
+ - sudo mv "$SCRATCH_DIR/ci.repo" /etc/yum.repos.d/
+ - sudo dnf install -y
+ libvirt-daemon-config-nwfilter
+ libvirt-daemon-config-network
+ libvirt-daemon-driver-interface
+ libvirt-daemon-driver-network
+ libvirt-daemon-driver-nodedev
+ libvirt-daemon-driver-nwfilter
+ libvirt-daemon-driver-qemu
+ libvirt-daemon-driver-secret
+ libvirt-daemon-driver-storage
+ perl-Sys-Virt
- sudo pip3 install --prefix=/usr avocado-framework
FYI, can be simplified to:
- sudo dnf install -y createrepo
- createrepo libvirt-rpms
- createrepo libvirt-perl-rpms
- dnf config-manager --add-repo libvirt-rpms
- dnf config-manager --add-repo libvirt-perl-rpms
- sudo dnf install -y
libvirt-daemon-config-nwfilter
libvirt-daemon-config-network
libvirt-daemon-qemu
perl-Sys-Virt
Not only does it require more steps, is ugly because of the heredoc
combined
with YAML's explicit line break preservation (|-), libvirt-daemon-driver-qemu
also doesn't pull all the needed bits as it was suggested, e.g.
libvirt-daemon-config-nwfilter which is needed by the tests. Although the tests
don't need virtinterfaced, I still had to include it because the logic which
restarts all the daemons would have to be adjusted as well; and then one day we
add a test for virtinterfaced we'd have to add it back, so IMO installing and
restarting all the daemons is the cleanest and most transparent way of setting
up the CI env even though we're not making use of all of it now (and so I ended
up naming all the secondary drivers explicitly).
NB, I suggested libvirt-daemon-qemu, not libvirt-daemon-driver-qemu,
because the former pulls in all the secondary driver packages, so
would only miss the config packages.
The other huge inconvenience with the proposed approach compared to
Peter's is
debugging the failures. What I currently do with any integration CI failures is
that I connect to the runner machine and spin up an instance of one of the
images from which gitlab provisions the environment, download the RPM artifacts
from libvirt and libvirt-perl, install and then debug - again, why? Because
unfortunately trying to do this locally is still less convenient even though
we've done plenty of work in lcitool to improve the status quo. So, back to
your suggestion - I'd have to create the repositories manually, install a few
explicit packages and then test; sorry, that maybe fine for the CI, but doesn't
beat the following in any way:
wget <libvirt-rpms-uri> -O libvirt_rpms.zip
wget <libvirt-perl-rpms-uri> -O libvirt_perl_rpms.zip
wget <libvirt-python-rpms-uri> -O libvirt_python_rpms.zip
unzip <yada yada>
dnf install libvirt_rpms/* libvirt_perl_rpms/* libvirt_python_rpms/*
That's fine as an approach for reproducing locally. Does it matter
that you're installing more packages that the CI system would have ?
I guess it could affect the results, but fairly slim liklihood IMHO.
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 :|