Il giorno mer 20 mar 2019 alle ore 11:07 Miguel Duarte de Mora Barroso <
mdbarroso@redhat.com> ha scritto:
On Wed, Mar 20, 2019 at 9:43 AM Miguel Duarte de Mora Barroso
<mdbarroso@redhat.com> wrote:
>
> On Tue, Mar 19, 2019 at 6:51 PM Anton Marchukov <amarchuk@redhat.com> wrote:
> >
> > Retrigger failed, seems to be the same error [1]?
>
> OK, taking a look now.
I noticed that it is installing a very old openvswitch version in
fedora - 2.8.1 - as you can check in the logs [0].
17:21:51 openvswitch.x86_64 2.8.1-2.fc28
17:21:51 openvswitch-ovn-central.x86_64 2.8.1-2.fc28
17:21:51 openvswitch-ovn-common.x86_64 2.8.1-2.fc28
17:21:51 openvswitch-ovn-host.x86_64 2.8.1-2.fc28
The 'check-patch' scripts have also begun failing for all my patches
on all targets *except* 4.2 - check [1].
On el7, it is grabbing version openvswitch.x86_64
1:2.9.0-4.el7 from centos-ovirt-4.2-el7.
ovirt-provider-ovn *requires* openvswitch 2.10 on 4.3 *and* master.
Sandro, this is just a theory, but to me it looks like
ovirt-provider-ovn master doesn't "know" it needs to get the packages
from the virt7-ovirt-43-testing tag or something alike.
I would start with adding
Requires: openvswitch >= 2.10
to ovirt-provider-ovn spec file.
ovirt-provider-ovn has a single branch, and on 4.2 we run on openvswitch-2.9, that's why we have simply relied on the tagged versions on ovirt-release.
Then yes, looks like OST is taking openvswitch from the wrong repo.
This is happening on the ovirt-provider-ovn integration tests, not only on OST.
I'm checking if updating the local repo config - e.g. automation/check-patch.repos.el7 to grab the 4.3 cbs tags work.