July 2022 - Devel - oVirt List Archives

[VDSM] Started getting virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired
by Edward Haas 11 Jan '24

11 Jan '24

Hi, I have a VM which acts as an oVirt host with VDSM installed. I use it for testing without connecting it to Engine. Recently VDSM fails to come up and I see this error: Sep 26 17:58:18 localhost libvirtd: 2018-09-26 14:58:18.978+0000: 12176: error : virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired Any hint on how to generate or fetch a new certificate without the help of Engine? Thanks, Edy.

3 5

Error: Adding new Host to ovirt-engine
by Ahmad Khiet 14 Aug '23

14 Aug '23

Hi, Can't add new host to ovirt engine, because the following error: 2019-06-12 12:23:09,664 p=4134 u=engine | TASK [ovirt-host-deploy-facts : Set facts] ************************************* 2019-06-12 12:23:09,684 p=4134 u=engine | ok: [10.35.1.17] => { "ansible_facts": { "ansible_python_interpreter": "/usr/bin/python2", "host_deploy_vdsm_version": "4.40.0" }, "changed": false } 2019-06-12 12:23:09,697 p=4134 u=engine | TASK [ovirt-provider-ovn-driver : Install ovs] ********************************* 2019-06-12 12:23:09,726 p=4134 u=engine | fatal: [10.35.1.17]: FAILED! => {} MSG: The conditional check 'cluster_switch == "ovs" or (ovn_central is defined and ovn_central | ipaddr and ovn_engine_cluster_version is version_compare('4.2', '>='))' failed. The error was: The ipaddr filter requires python's netaddr be installed on the ansible controller The error appears to be in '/home/engine/apps/engine/share/ovirt-engine/playbooks/roles/ovirt-provider-ovn-driver/tasks/configure.yml': line 3, column 5, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - block: - name: Install ovs ^ here 2019-06-12 12:23:09,728 p=4134 u=engine | PLAY RECAP ********************************************************************* 2019-06-12 12:23:09,728 p=4134 u=engine | 10.35.1.17 : ok=3 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 whats missing!? Thanks -- Ahmad Khiet Red Hat <https://www.redhat.com/> akhiet(a)redhat.com M: +972-54-6225629 <https://red.ht/sig>

7 10

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

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

Vdsm development documentation at oVirt site
by Milan Zamazal 18 Jul '22

18 Jul '22

Hi, the Vdsm development documentation at https://ovirt.org/develop/developer-guide/vdsm/developers.html is outdated. Thanks to the effort especially from the storage team, there have been updates to the development documentation in the Vdsm repository itself recently. I think that rather than maintaining duplicate documentation in the repository and on the web, it would be better to replace the documentation on the web with pointers to the contents in Vdsm GitHub repository. And adding the remaining pieces from the web to the repo, if anything is missing there. Any objections? And any volunteers? ;-) Thanks, Milan

2 3

ovirt-engine has been tagged (ovirt-engine-4.5.1.3)
by Martin Perina 04 Jul '22

04 Jul '22

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

1 0

ovirt-manager: are two OpenJDK really needed?
by aperotti+ovirt＠redhat.com 02 Jul '22

02 Jul '22

Hi, I'm setting up a new environment with 4.5.1 on top of RHEL, and I've noticed that when I install ovirt-engine, not one but two openjdk are installed on my system: # dnf install ovirt-engine Dependencies resolved. ============================================================================================================================================= Package Arch Version Repository Size ============================================================================================================================================= Installing: ovirt-engine noarch 4.5.1.2-1.el8 ovirt-45-upstream 14 M Installing dependencies: [...] java-1.8.0-openjdk-headless x86_64 1:1.8.0.332.b09-2.el8_6 rhel-8-for-x86_64-appstream-rpms 34 M java-11-openjdk-headless x86_64 1:11.0.15.0.10-2.el8_6 rhel-8-for-x86_64-appstream-rpms 40 M Are both really needed? Isn't it possible to just rely on java 8? I've tried to mask each and it looks like both are required by the ovirt-engine... [java-11-openjdk-headless masked] Error: Problem: package ovirt-engine-4.5.1.2-1.el8.noarch requires java-11-openjdk-headless >= 11.0.11, but none of the providers can be installed - cannot install the best candidate for the job [java-1.8.0-openjdk-headless masked] Error: Problem: package ovirt-engine-4.5.1.2-1.el8.noarch requires java-headless, but none of the providers can be installed - cannot install the best candidate for the job I'm asking this for resources optimization and for long term support, because they have different lifecycle [1]: OpenJDK 8 May 2026 8.0.0 OpenJDK 11 Oct 2024 8.0.0 OpenJDK 17 Dec 2027 8.5 Is it a bug or an unnoticed dependency situation so should I open a BZ for it? Or is it a known situation, cannot be avoided to have 2 openjdk so I should open an RFE asking if the dependency can be moved from java-11 to i.e. java-17 in order to have longer support? Thanks for guidance, [1] https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycl…

1 0