- Devel - oVirt List Archives

Change in DNF COPR plugin requires action
by Marcin Sobczyk 23 Aug '22

23 Aug '22

Hi All, recently there was a PR merged to DNF COPR plugin [1] that makes the default chroot on CentOS Stream 9 to be 'epel-9'. Because of this we now need to specify the 'centos-stream-9' chroot name that we use in oVirt COPR explicitly, i.e.: dnf copr enable -y ovirt/ovirt-master-snapshot centos-stream-9 I can see there's a bunch of places throughout our projects that need an update. I'll post PRs for the ones I can spot. Regards, Marcin [1] https://github.com/rpm-software-management/dnf-plugins-core/pull/459/files

2 3

ovirt-engine-4.5.2.4 has been tagged
by Martin Perina 19 Aug '22

19 Aug '22

ovirt-engine-4.5.2.4 has been tagged -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.

1 0

github testing: merge with branch, or use PR HEAD?
by Yedidyah Bar David 17 Aug '22

17 Aug '22

Hi all, I was annoyed for some time now by the fact that when I used some github-CI-generated RPMs, with a git hash in their names, I could never find this git hash anywhere - not in my local git repo, nor in github. Why is it so? Because, if I got it right, the default for 'actions/checkout@v2' is to merge the PR HEAD with the branch HEAD. See e.g. [1]: HEAD is now at 7bbb40c9a Merge 026bb9c672bf46786dd6d16f4cbe0ecfa84c531d into 35e217936b5571e9657946b47333a563373047bb Meaning: my patch was 026bb9c, master was 35e2179, and the generated RPMs will have 7bbb40c9a, not to be found anywhere else. If you check the main PR page [3], you can find there '026bb9c', but not '7bbb40c9a'. (Even 026bb9c might require some effort, e.g. "didib force-pushed the add-hook-log-console branch 2 times, most recently from c90e658 to 66ebc88 yesterday". I guess this is the result of github discouraging force-pushes, in direct opposite of gerrit, which had a notion of different patchsets for a single change. I already ranted about this in the past, but that's not the subject of the current message). This is not just an annoyance, it's a real difference in semantics. In gerrit/jenkins days, IIRC most/all projects I worked on, ran CI testing/building on the pushed HEAD, and didn't touch it. Rebase, if at all, happened either explicitly, or at merge time. actions/checkout's default, to auto-merge, is probably meant to be more "careful" - to test what would happen if the code is merged. I agree this makes sense. But I personally think it's almost always ok to test on the pushed HEAD and not rebase/merge _implicitely_. What do you think? It should be easy to change, using [2]: - uses: actions/checkout@v2 with: ref: ${{ github.event.pull_request.head.sha }} No need to reach a complete consensus - can be decided upon per-project/repo. But if you disagree, I'd like to understand why. Thanks. Best regards, [1] https://github.com/oVirt/vdsm/runs/6881311961?check_suite_focus=true [2] https://github.com/marketplace/actions/checkout?version=v2.4.2#checkout-pul… [3] https://github.com/oVirt/vdsm/pull/249 -- Didi

6 16

ovirt-engine-4.5.2.2 has been tagged
by Martin Perina 10 Aug '22

10 Aug '22

ovirt-engine-4.5.2.2 has been tagged -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.

1 0

Starting with oVirt
by Teemu Saarinen 03 Aug '22

03 Aug '22

Hi, Our company is planning of taking oVirt in into our environment. We would have a few questions for that if you could guide us. Hardware: What would be the minimum configuration for us using oVirt?. Idea would be to replace all our current Linux and Windows servers with oVirt. There are currently 24 servers in use. The goal would also be that the virtual servers could be migrated live and also in the HA configuration, i.e. if one hardware crashes execution continues on the other. As far as I understand Ovirt enables this? So we would like to know what kind of hardware (minimum) we should have for this size of environment? Storagin: Do all machines need a lot of hard disk space or is it enough to have only one or two? I'm referring to shared storage. Can you also have storagin as HA? Host: What happens to HOST1 and HOST2 virtual machines if the oVirt host server crashes? Do they continue to operate without it, or do they crash at the same time? Thank You! Teemu S.

1 0

ovirt-engine-4.5.2.1 has been tagged
by Martin Perina 03 Aug '22

03 Aug '22

ovirt-engine-4.5.2.1 has been tagged -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.

1 0

Obsoleting Packages in 'dnf check-update' on RHEL 8.6 hosts
by Scott Worthington 01 Aug '22

01 Aug '22

Hello, My 4.5.1.3-1.el8 oVirt homelab cluster is running on RHEL 8.6 hosts and a RHEL 8.6 stand-alone engine. During the installation, I followed the instructions for RHEL 8.6: https://ovirt.org/download/install_on_rhel.html After the installation is complete, all packages are up-to-date, and everything is running, I run a 'dnf check-upgrade' and I find there are two packages that are listed under "Obsoleting Packages": """ Last metadata expiration check: 0:43:06 ago on Mon 01 Aug 2022 08:08:50 AM EDT. Obsoleting Packages centos-stream-release.noarch 8.6-1.el8 @@System centos-stream-release.noarch 8.6-1.el8 @@System centos-stream-release.noarch 8.6-1.el8 @@System redhat-release.x86_64 8.6-0.1.el8 @rhel-8-for-x86_64-baseos-rpms """ For the hosts, it makes it appear that the hosts always have an upgrade pending in the oVirt Engine UI. "centos-strea-release.noarch" appears to contain similar files to the original RHEL 8.6 package "redhat-release-8.6.0.1.el8" except for the addition of "centos*" named files. Any thoughts on how to change this behavior so that it doesn't appear to have packages to upgrade because a 'dnf update' does nothing to these "Obsoleting Packages"? Thanks in advance.

1 0

Vdsm: ovirt-4.5.2.z branch created
by Milan Zamazal 01 Aug '22

01 Aug '22

Hi, a branch for 4.5.2 fixes was created. You can merge stuff for 4.5.3 to master now. Regards, Milan

1 0

oVirt Survey Summer 2022 responses are now available
by Sandro Bonazzola 01 Aug '22

01 Aug '22

Thanks to the 109 participants in the oVirt Survey Summer 2022! The survey is now over and results are publicly available at https://docs.google.com/forms/d/1eQcbSqC6JQ2mvbPUcD7S_0pZW8hy_De4PCwkBYrP6m… Thanks -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D PERFORMANCE & SCALE Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

1 0

Update project settings for required CI tests in vdsm and ovirt-imageio
by Albert Esteve 18 Jul '22

18 Jul '22

Hi all, We have recently updated the CI tests in the vdsm repository, and split storage tests into 'test-storage-root" and "test-storage-user". However, the latter is still named "test-storage" ( https://github.com/oVirt/vdsm/blob/master/.github/workflows/ci.yml#L13) as it was a required CI job in the project settings. Ideally, we would need a project owner (or someone with write permissions) to remove "test-storage" from the project requirements and add "test-storage-user" instead, for consistency. Similarly, in ovirt-imageio, centos-8 and fedora-35 shall be removed in favor of their current counterparts: https://github.com/oVirt/ovirt-imageio/pull/99 Otherwise, the branch above cannot be integrated. I do not have the permissions, but in my fork I found the place where to change it (i.e., the branches settings): [image: image.png] Could someone with permissions take a look? Thanks in advance! BR, Albert Esteve Senior Software Engineer Red Hat <https://www.redhat.com/> aesteve(a)redhat.com <https://www.redhat.com/>

2 1