I am getting other failed CI's in other repositories: *Api-model:* fatal: unable to access 'https://gerrit.ovirt.org/jenkins/': Could not resolve host: gerrit.ovirt.org; Unknown error Link: https://jenkins.ovirt.org/job/ovirt-engine-api-model_standard-check-patch... *OST:* failing on: Error: Unable to find a match: python3-ansible-runner Link: https://ovirt-devops-jenkins.upshift.rdu2.redhat.com/job/ovirt-system-tes... Thanks, Saif On Thu, Dec 9, 2021 at 3:04 PM Milan Zamazal <mzamazal(a)redhat.com&gt; wrote:

On Tue, Dec 14, 2021 at 12:32 AM Nir Soffer <nsoffer(a)redhat.com&gt; wrote: I tried this here: https://gerrit.ovirt.org/c/vdsm/+/118022

On Tue, Dec 14, 2021 at 12:13 PM Nir Soffer <nsoffer(a)redhat.com&gt; wrote: ... Current state: https://gerrit.ovirt.org/q/topic:thin-scratch-disks+is:open 6 patches ready for merge. 3 OST runs started successfully 3 build artifacts failed (50% success rate) - I retriggered the failed runs Al the failures happened on el7-worker-02: - https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-... - https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-... - https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-... Build history for this host - all builds fail in the last 4 days: https://jenkins.ovirt.org/computer/el7-worker-02/builds Build history for other hosts: https://jenkins.ovirt.org/computer/el7-worker-03/builds Nir

Hi, After digging to the issues we see that el7-worker-02 had dhcp configuration issues. There were changes in the dhcp configuration last week thus making the dns not resolvable. For further information about it see: https://issues.redhat.com/browse/CPDEVOPS-407 <https://issues.redhat.com/browse/CPDEVOPS-407> After rebooting the vm, it is now working. Regards, Ehud.

On Tue, Dec 14, 2021 at 10:14 AM Milan Zamazal <mzamazal(a)redhat.com&gt; wrote: This is not that bad, I'm using this flow for a few years: while work needed: hack... push -f github # push to my github fork check the build in github git review # push to gerrit for review Yes. I think what we need is a way to start OST build with a github pull request url: CUSTOM_REPOS=https://github.com/oVirt/{project}/pull/{7} Or if it is easier, a way to upload zip files to jenkins for running OST. Once we have something like this, we can move vdsm to github. Triggering OST builds automatically ("gating") is nice to have and can be done later. Nir

.On Tue, Dec 14, 2021 at 11:15 AM Vojtech Juranek <vjuranek(a)redhat.com&gt; wrote: ... This requires Personal Access Token: https://docs.github.com/en/authentication/keeping-your-account-and-data-s... So we need to add a github users with PAT that can download the built artifacts. We need to find the artifacts in the build, likey using github API. For example: https://github.com/oVirt/ovirt-imageio/actions/runs/1573283335 The artifact we need is the centos-8.zip: https://github.com/oVirt/ovirt-imageio/suites/4639547952/artifacts/125747744 The URL does not tell us that this is the centos stream 8 artifact, so we need a way to locate it programatically. This is for a single host, all hosts in OST need to use the new repo. Another option is to have a web server serving built rpms, e.g. https://repo.ost.example.com/ And unzip each built rpm before the test to: /serverroot/93d9ee4f-4cda-403a-a29d-9a3669ee49af/ So we have this layout: /serverroot/ 93d9ee4f-4cda-403a-a29d-9a3669ee49af/ repodata/ *.rpm ... And start the OST job with: CUSTOM_REPOS=https://repo.ost.example.com/93d9ee4f-4cda-403a-a29d-9a3669e... When the OST job finish, delete /serverroot/93d9ee4f-4cda-403a-a29d-9a3669ee49af/ This can also work with multiple pull requests, e.g. testing both vdsm and engine pull request at the same time. Nir