Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rpm: Update virtualization packages #12452

Merged
merged 2 commits into from
Jul 25, 2024

Conversation

andreabolognani
Copy link
Contributor

What this PR does

Update virtualization packages. Specifically:

  • QEMU (8.2.0 → 9.0.0)
  • libvirt (10.0.0 → 10.5.0)
  • EDKII (20231122 → 20240524)
  • passt (20231204 → 20240624)
  • virtiofsd (1.10.1 → 1.11.1)

This PR is a superset of #12300.

Release note

This version of KubeVirt includes upgraded virtualization technology based on libvirt 10.5.0 and QEMU 9.0.0.
Each new release of libvirt and QEMU contains numerous improvements and bug fixes.

Specifically:

       QEMU        8.2.0 -> 9.0.0
    libvirt       10.0.0 -> 10.5.0
      EDKII     20231122 -> 20240524
      passt     20231204 -> 20240624
  virtiofsd       1.10.1 -> 1.11.1

Note that libgcrypt is no longer included in the libvirt-devel
rpmtree, and all references to it had to be removed from the
corresponding bazeldnf ldd rules otherwise the RPM update
process wouldn't successfully complete.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
To match the RPM update.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
@kubevirt-bot kubevirt-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. size/XXL sig/buildsystem Denotes an issue or PR that relates to changes in the build system. labels Jul 24, 2024
Copy link
Member

@brianmcarey brianmcarey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

thanks @andreabolognani !

I just noticed something strange in the WORKSPACE but I guess those changes were just from the automation?

WORKSPACE Show resolved Hide resolved
@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Jul 25, 2024
@andreabolognani
Copy link
Contributor Author

@jean-edouard can you perhaps approve this one? You had taken a stab at it already, so you should be familiar with the matter :)

urls = [
"http://mirror.stream.centos.org/9-stream/BaseOS/aarch64/os/Packages/binutils-2.35.2-43.el9.aarch64.rpm",
"https://storage.googleapis.com/builddeps/6814f37a59d417143be795b8435df1127ed0a71e86d74d00120007f694f085a2",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR appears to remove all the googleapi.com mirrors, we need to keep those.
I've seen that happen before when running make rpm-deps, I'm not sure what needs to be done differently...
@dhiller any insight?
Thanks

Copy link
Member

@brianmcarey brianmcarey Jul 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These get added by an automatic PR once the artifacts are mirrored to the GCS bucket. These newer rpms have to be merged first and then the periodic mirror job will upload them and create a PR.

This is an example of the mirror PR that I am talking about - #11916

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect, thanks!
/approve

@kubevirt-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jean-edouard

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubevirt-bot kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 25, 2024
@kubevirt-commenter-bot
Copy link

Required labels detected, running phase 2 presubmits:
/test pull-kubevirt-e2e-windows2016
/test pull-kubevirt-e2e-kind-1.27-vgpu
/test pull-kubevirt-e2e-kind-sriov
/test pull-kubevirt-e2e-k8s-1.30-ipv6-sig-network
/test pull-kubevirt-e2e-k8s-1.28-sig-network
/test pull-kubevirt-e2e-k8s-1.28-sig-storage
/test pull-kubevirt-e2e-k8s-1.28-sig-compute
/test pull-kubevirt-e2e-k8s-1.28-sig-operator
/test pull-kubevirt-e2e-k8s-1.29-sig-network
/test pull-kubevirt-e2e-k8s-1.29-sig-storage
/test pull-kubevirt-e2e-k8s-1.29-sig-compute
/test pull-kubevirt-e2e-k8s-1.29-sig-operator

@kubevirt-bot kubevirt-bot merged commit 2325ed3 into kubevirt:main Jul 25, 2024
41 checks passed
@andreabolognani
Copy link
Contributor Author

Thanks @brianmcarey @jean-edouard!

@Barakmor1
Copy link
Member

@andreabolognani @jean-edouard Shouldn't we backport it since the virtualization packages include bug fixes?

@jean-edouard
Copy link
Contributor

@andreabolognani @jean-edouard Shouldn't we backport it since the virtualization packages include bug fixes?

Do you have specific bugs in mind? Maybe the fixes were backported in z-streams upstream and we could target those?
In general, package updates will always contain bug fixes...

@Barakmor1
Copy link
Member

Barakmor1 commented Sep 25, 2024

@jean-edouard this one:
#12519

Maybe the fixes were backported in z-streams upstream and we could target those?

Sounds good to me if this is the case

@jean-edouard
Copy link
Contributor

@jean-edouard this one: #12519

Maybe the fixes were backported in z-streams upstream and we could target those?

Sounds good to me if this is the case

@andreabolognani what do you think? I don't see any z-stream release in download.libvirt.org, does it make sense to upgrade release branche(s) from 10.0 to 10.5? Can that be done without updating the other packages? Backporting this entire PR feels wrong but maybe it is the right thing to do after all...

@andreabolognani
Copy link
Contributor Author

I don't see any z-stream release in download.libvirt.org

@jean-edouard z-stream is a purely downstream concept. The closest upstream equivalent would be stable/maintenance releases, but in the case of libvirt we only do those extremely rarely.

does it make sense to upgrade release branche(s) from 10.0 to 10.5? Can that be done without updating the other packages? Backporting this entire PR feels wrong but maybe it is the right thing to do after all...

If you have specific, targeted issues that you're concerned about then you might be able to make a case for the fixes being backported from RHEL 9.5 (libvirt 10.5.0) to RHEL 9.4 (libvirt 10.0.0), and then you could pick the new libvirt 10.0.0 package that contains them for use in the stable KubeVirt branch.

Backporting the RPM update in its entirety, or even just bumping libvirt from 10.0.0 to 10.5.0 on its own, seems contrary to the very idea of a stable branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/buildsystem Denotes an issue or PR that relates to changes in the build system. size/XXL
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants