Check-Merged Fails for ovirt-provider-ovn
Hello. I note that check-merged for ovirt-provider-ovn [1] fails on the following:
assert len(networks) == 1
E AssertionError: assert 2 == 1 E + where 2 = len([{'id': 'e0e73fc4-88e1-41e4-91c9-c9519c02f319', 'mtu': 1442, 'name': 'net1', 'port_security_enabled': False, ...}, {'id': '34d40d1f-b2e3-4eb9-9202-6d311162ea5a', 'mtu': 1442, 'name': 'ls0', 'port_security_enabled': False, ...}]) test_provider_api.py:72: AssertionError seems like the unit tests are failing. This is not OST failure itself, but it happens right before that on the build stage and hence this project fails in the Change Queue, so we need to check it. [1] https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/ Anton. -- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
On Tue, Mar 19, 2019 at 2:55 PM Anton Marchukov <amarchuk@redhat.com> wrote:
Hello.
I note that check-merged for ovirt-provider-ovn [1] fails on the following:
assert len(networks) == 1
E AssertionError: assert 2 == 1 E + where 2 = len([{'id': 'e0e73fc4-88e1-41e4-91c9-c9519c02f319', 'mtu': 1442, 'name': 'net1', 'port_security_enabled': False, ...}, {'id': '34d40d1f-b2e3-4eb9-9202-6d311162ea5a', 'mtu': 1442, 'name': 'ls0', 'port_security_enabled': False, ...}]) test_provider_api.py:72: AssertionError
seems like the unit tests are failing. This is not OST failure itself, but it happens right before that on the build stage and hence this project fails in the Change Queue, so we need to check it.
According to the logs, ovs bridge br-int is not available; this sometimes happens, making ovn-controller crash, I think it is a manifestation of bug [0]. Can the build be re-triggered ? I've never been able to reproduce it locally, thus this taking so long to figure out. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1685058
[1] https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/
Anton.
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/SXDUKBQ4F77WNB...
I retriggered. Will see.
On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso <mdbarroso@redhat.com> wrote:
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
Retrigger failed, seems to be the same error [1]? [1] https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/
On 19 Mar 2019, at 17:10, Anton Marchukov <amarchuk@redhat.com> wrote:
I retriggered. Will see.
On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso <mdbarroso@redhat.com> wrote:
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
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.
[1] https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/
On 19 Mar 2019, at 17:10, Anton Marchukov <amarchuk@redhat.com> wrote:
I retriggered. Will see.
On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso <mdbarroso@redhat.com> wrote:
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
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've tried locally to revert patch [2] that added the 4.3 branch to the provider; it fixed this, but I think that's just masking the problem. [0] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/conso... [1] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_master_check-patch-el7-x86_... [2] - https://gerrit.ovirt.org/#/c/98565/
[1] https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/
On 19 Mar 2019, at 17:10, Anton Marchukov <amarchuk@redhat.com> wrote:
I retriggered. Will see.
On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso <mdbarroso@redhat.com> wrote:
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
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. Then yes, looks like OST is taking openvswitch from the wrong repo. Dafna, can you fix OST repo config for taking openvswitch from https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on EL7 and https://copr-be.cloud.fedoraproject.org/results/mdbarroso/openvswitch/fedora... for Fedora?
I've tried locally to revert patch [2] that added the 4.3 branch to the provider; it fixed this, but I think that's just masking the problem.
[0] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/conso... [1] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_master_check-patch-el7-x86_... [2] - https://gerrit.ovirt.org/#/c/98565/
[1]
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/
On 19 Mar 2019, at 17:10, Anton Marchukov <amarchuk@redhat.com>
wrote:
I retriggered. Will see.
On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso <
mdbarroso@redhat.com> wrote:
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
-- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig>
On Wed, Mar 20, 2019 at 12:44 PM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
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.
We don't want to force installation of provider and OvS on the same host/container. But we can add a Conflicts < 2.10 line.
Then yes, looks like OST is taking openvswitch from the wrong repo. Dafna, can you fix OST repo config for taking openvswitch from https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on EL7 and
https://copr-be.cloud.fedoraproject.org/results/mdbarroso/openvswitch/fedora... for Fedora?
I've tried locally to revert patch [2] that added the 4.3 branch to the provider; it fixed this, but I think that's just masking the problem.
[0] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/conso... [1] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_master_check-patch-el7-x86_... [2] - https://gerrit.ovirt.org/#/c/98565/
[1]
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/
On 19 Mar 2019, at 17:10, Anton Marchukov <amarchuk@redhat.com>
wrote:
I retriggered. Will see.
On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso <
mdbarroso@redhat.com> wrote:
>
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig>
Il giorno mer 20 mar 2019 alle ore 11:55 Dan Kenigsberg <danken@redhat.com> ha scritto:
On Wed, Mar 20, 2019 at 12:44 PM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
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.
We don't want to force installation of provider and OvS on the same host/container. But we can add a Conflicts < 2.10 line.
I think you're kind of abusing the meaning of Conflicts to workaround a RPM limitation regarding containerization but I won't stop you from doing that. I tend to think this won't pass a fedora review session.
Then yes, looks like OST is taking openvswitch from the wrong repo. Dafna, can you fix OST repo config for taking openvswitch from https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on EL7 and
https://copr-be.cloud.fedoraproject.org/results/mdbarroso/openvswitch/fedora... for Fedora?
I've tried locally to revert patch [2] that added the 4.3 branch to the provider; it fixed this, but I think that's just masking the problem.
[0] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/conso... [1] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_master_check-patch-el7-x86_... [2] - https://gerrit.ovirt.org/#/c/98565/
[1]
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/
On 19 Mar 2019, at 17:10, Anton Marchukov <amarchuk@redhat.com>
wrote:
I retriggered. Will see.
> On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso <
mdbarroso@redhat.com> wrote:
> >> https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig>
-- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig>
On Wed, Mar 20, 2019 at 11:44 AM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
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. Dafna, can you fix OST repo config for taking openvswitch from https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on EL7 and
https://copr-be.cloud.fedoraproject.org/results/mdbarroso/openvswitch/fedora... for Fedora?
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.
I've tried locally to revert patch [2] that added the 4.3 branch to the provider; it fixed this, but I think that's just masking the problem.
[0] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/conso... [1] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_master_check-patch-el7-x86_... [2] - https://gerrit.ovirt.org/#/c/98565/
[1]
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/
On 19 Mar 2019, at 17:10, Anton Marchukov <amarchuk@redhat.com>
wrote:
I retriggered. Will see.
On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso <
mdbarroso@redhat.com> wrote:
>
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig>
On Wed, Mar 20, 2019 at 12:45 PM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
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.
Then yes, looks like OST is taking openvswitch from the wrong repo. Dafna, can you fix OST repo config for taking openvswitch from https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on EL7 and
Dafna is on sick leave, In order to simplify the reposync file we dropped inlude list for all centos small repos so you won't need to handle whitelisting everything a new pkgs is out. If a package is in multiple repos, YUM should bring always the highest version which is normal behavior for YUM afaik. If there are specific repos you know for a fact you don't want pkgs taken from there, please add exclude from that repo. I don't even see https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on reposync, is that a new repo?
https://copr-be.cloud.fedoraproject.org/results/mdbarroso/openvswitch/fedora... for Fedora?
If its needed for the project itself (check-patch) the project owner should update it in their automation/check-patch.fc28 file: cat check-merged.repos.fc28 ovirt-snapshot-static, http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/$distro mdbarroso-python-ovsdbapp, https://copr-be.cloud.fedoraproject.org/results/mdbarroso/ovsdbapp/fedora-$r... tested,http://resources.ovirt.org/repos/ovirt/tested/master/rpm/$distro virt-preview, http://fedorapeople.org/groups/virt/virt-preview/fedora-$releasever/$basearc...
I've tried locally to revert patch [2] that added the 4.3 branch to the provider; it fixed this, but I think that's just masking the problem.
[0] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/conso... [1] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_master_check-patch-el7-x86_... [2] - https://gerrit.ovirt.org/#/c/98565/
[1]
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/
On 19 Mar 2019, at 17:10, Anton Marchukov <amarchuk@redhat.com>
wrote:
I retriggered. Will see.
On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso <
mdbarroso@redhat.com> wrote:
>
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig> _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/4GWFMJTRWF6Y42...
-- Eyal edri MANAGER RHV/CNV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
Il giorno mer 20 mar 2019 alle ore 12:33 Eyal Edri <eedri@redhat.com> ha scritto:
On Wed, Mar 20, 2019 at 12:45 PM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
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.
Then yes, looks like OST is taking openvswitch from the wrong repo. Dafna, can you fix OST repo config for taking openvswitch from https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on EL7 and
Dafna is on sick leave, In order to simplify the reposync file we dropped inlude list for all centos small repos so you won't need to handle whitelisting everything a new pkgs is out. If a package is in multiple repos, YUM should bring always the highest version which is normal behavior for YUM afaik. If there are specific repos you know for a fact you don't want pkgs taken from there, please add exclude from that repo.
I don't even see https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on reposync, is that a new repo?
No, it's just the testing repo generated by the sum of http://cbs.centos.org/repos/virt7-ovirt-common-testing/x86_64/os/ and http://cbs.centos.org/repos/virt7-ovirt-43-testing/x86_64/os/
https://copr-be.cloud.fedoraproject.org/results/mdbarroso/openvswitch/fedora... for Fedora?
If its needed for the project itself (check-patch) the project owner should update it in their automation/check-patch.fc28 file:
cat check-merged.repos.fc28 ovirt-snapshot-static, http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/$distro mdbarroso-python-ovsdbapp, https://copr-be.cloud.fedoraproject.org/results/mdbarroso/ovsdbapp/fedora-$r... tested,http://resources.ovirt.org/repos/ovirt/tested/master/rpm/$distro virt-preview, http://fedorapeople.org/groups/virt/virt-preview/fedora-$releasever/$basearc...
I've tried locally to revert patch [2] that added the 4.3 branch to the provider; it fixed this, but I think that's just masking the problem.
[0] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/conso... [1] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_master_check-patch-el7-x86_... [2] - https://gerrit.ovirt.org/#/c/98565/
[1]
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/
On 19 Mar 2019, at 17:10, Anton Marchukov <amarchuk@redhat.com>
wrote:
I retriggered. Will see.
> On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso <
mdbarroso@redhat.com> wrote:
> >> https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig> _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/4GWFMJTRWF6Y42...
--
Eyal edri
MANAGER
RHV/CNV DevOps
EMEA VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
-- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig>
On Wed, Mar 20, 2019 at 1:31 PM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
Il giorno mer 20 mar 2019 alle ore 12:33 Eyal Edri <eedri@redhat.com> ha scritto:
On Wed, Mar 20, 2019 at 12:45 PM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
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.
Then yes, looks like OST is taking openvswitch from the wrong repo. Dafna, can you fix OST repo config for taking openvswitch from https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on EL7 and
This failure was unrelated to OST - it happened on the ovirt-provider-ovn integration test environment. We use the tripleo-ovn containers to check the data plane connectivity that ovirt-provider-ovn configures. The controller container was updated, 2 days ago, and for whatever reason, it breaks our CI. By selecting a different container image we managed to get CI to pass in patch [0], which is already merged. I'll look at the root cause when I can find the time. @Anton Marchukov <amarchuk@redhat.com> I'll keep an eye out for the check-merged target of the aforementioned patch; I'll update you once it finishes. [0] - https://gerrit.ovirt.org/#/c/98698/
Dafna is on sick leave, In order to simplify the reposync file we dropped inlude list for all centos small repos so you won't need to handle whitelisting everything a new pkgs is out. If a package is in multiple repos, YUM should bring always the highest version which is normal behavior for YUM afaik. If there are specific repos you know for a fact you don't want pkgs taken from there, please add exclude from that repo.
I don't even see https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on reposync, is that a new repo?
No, it's just the testing repo generated by the sum of http://cbs.centos.org/repos/virt7-ovirt-common-testing/x86_64/os/ and http://cbs.centos.org/repos/virt7-ovirt-43-testing/x86_64/os/
https://copr-be.cloud.fedoraproject.org/results/mdbarroso/openvswitch/fedora... for Fedora?
If its needed for the project itself (check-patch) the project owner should update it in their automation/check-patch.fc28 file:
cat check-merged.repos.fc28 ovirt-snapshot-static, http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/$distro mdbarroso-python-ovsdbapp, https://copr-be.cloud.fedoraproject.org/results/mdbarroso/ovsdbapp/fedora-$r... tested,http://resources.ovirt.org/repos/ovirt/tested/master/rpm/$distro virt-preview, http://fedorapeople.org/groups/virt/virt-preview/fedora-$releasever/$basearc...
I've tried locally to revert patch [2] that added the 4.3 branch to the provider; it fixed this, but I think that's just masking the problem.
[0] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/conso... [1] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_master_check-patch-el7-x86_... [2] - https://gerrit.ovirt.org/#/c/98565/
[1]
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/
> On 19 Mar 2019, at 17:10, Anton Marchukov <amarchuk@redhat.com>
wrote:
> > I retriggered. Will see. > >> On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso < mdbarroso@redhat.com> wrote: >> >>> https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/ > > -- > Anton Marchukov > Associate Manager - RHV DevOps - Red Hat > > > > > >
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig> _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/4GWFMJTRWF6Y42...
--
Eyal edri
MANAGER
RHV/CNV DevOps
EMEA VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig>
On Wed, Mar 20, 2019 at 4:13 PM Miguel Duarte de Mora Barroso < mdbarroso@redhat.com> wrote:
On Wed, Mar 20, 2019 at 1:31 PM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
Il giorno mer 20 mar 2019 alle ore 12:33 Eyal Edri <eedri@redhat.com> ha scritto:
On Wed, Mar 20, 2019 at 12:45 PM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
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.
Then yes, looks like OST is taking openvswitch from the wrong repo. Dafna, can you fix OST repo config for taking openvswitch from https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on EL7 and
This failure was unrelated to OST - it happened on the ovirt-provider-ovn integration test environment.
We use the tripleo-ovn containers to check the data plane connectivity that ovirt-provider-ovn configures. The controller container was updated, 2 days ago, and for whatever reason, it breaks our CI.
By selecting a different container image we managed to get CI to pass in patch [0], which is already merged. I'll look at the root cause when I can find the time.
@Anton Marchukov <amarchuk@redhat.com> I'll keep an eye out for the check-merged target of the aforementioned patch; I'll update you once it finishes.
Aaaaaaaaaaaaaaaaand it's good. CI is back to normal. pheew.
[0] - https://gerrit.ovirt.org/#/c/98698/
Dafna is on sick leave, In order to simplify the reposync file we dropped inlude list for all centos small repos so you won't need to handle whitelisting everything a new pkgs is out. If a package is in multiple repos, YUM should bring always the highest version which is normal behavior for YUM afaik. If there are specific repos you know for a fact you don't want pkgs taken from there, please add exclude from that repo.
I don't even see https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on reposync, is that a new repo?
No, it's just the testing repo generated by the sum of http://cbs.centos.org/repos/virt7-ovirt-common-testing/x86_64/os/ and http://cbs.centos.org/repos/virt7-ovirt-43-testing/x86_64/os/
https://copr-be.cloud.fedoraproject.org/results/mdbarroso/openvswitch/fedora... for Fedora?
If its needed for the project itself (check-patch) the project owner should update it in their automation/check-patch.fc28 file:
cat check-merged.repos.fc28 ovirt-snapshot-static, http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/$distro mdbarroso-python-ovsdbapp, https://copr-be.cloud.fedoraproject.org/results/mdbarroso/ovsdbapp/fedora-$r... tested,http://resources.ovirt.org/repos/ovirt/tested/master/rpm/$distro virt-preview, http://fedorapeople.org/groups/virt/virt-preview/fedora-$releasever/$basearc...
I've tried locally to revert patch [2] that added the 4.3 branch to the provider; it fixed this, but I think that's just masking the problem.
[0] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/conso... [1] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_master_check-patch-el7-x86_... [2] - https://gerrit.ovirt.org/#/c/98565/
> > [1]
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/
> > > On 19 Mar 2019, at 17:10, Anton Marchukov <amarchuk@redhat.com> wrote: > > > > I retriggered. Will see. > > > >> On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso < mdbarroso@redhat.com> wrote: > >> > >>> https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/ > > > > -- > > Anton Marchukov > > Associate Manager - RHV DevOps - Red Hat > > > > > > > > > > > > > > -- > Anton Marchukov > Associate Manager - RHV DevOps - Red Hat > > > > > >
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig> _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/4GWFMJTRWF6Y42...
--
Eyal edri
MANAGER
RHV/CNV DevOps
EMEA VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig>
Hello Miguel. Great! Thanks.
On 20 Mar 2019, at 16:47, Miguel Duarte de Mora Barroso <mdbarroso@redhat.com> wrote:
On Wed, Mar 20, 2019 at 4:13 PM Miguel Duarte de Mora Barroso <mdbarroso@redhat.com> wrote:
On Wed, Mar 20, 2019 at 1:31 PM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
Il giorno mer 20 mar 2019 alle ore 12:33 Eyal Edri <eedri@redhat.com> ha scritto:
On Wed, Mar 20, 2019 at 12:45 PM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
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.
Then yes, looks like OST is taking openvswitch from the wrong repo. Dafna, can you fix OST repo config for taking openvswitch from https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on EL7 and
This failure was unrelated to OST - it happened on the ovirt-provider-ovn integration test environment.
We use the tripleo-ovn containers to check the data plane connectivity that ovirt-provider-ovn configures. The controller container was updated, 2 days ago, and for whatever reason, it breaks our CI.
By selecting a different container image we managed to get CI to pass in patch [0], which is already merged. I'll look at the root cause when I can find the time.
@Anton Marchukov I'll keep an eye out for the check-merged target of the aforementioned patch; I'll update you once it finishes.
Aaaaaaaaaaaaaaaaand it's good. CI is back to normal. pheew.
[0] - https://gerrit.ovirt.org/#/c/98698/
Dafna is on sick leave, In order to simplify the reposync file we dropped inlude list for all centos small repos so you won't need to handle whitelisting everything a new pkgs is out. If a package is in multiple repos, YUM should bring always the highest version which is normal behavior for YUM afaik. If there are specific repos you know for a fact you don't want pkgs taken from there, please add exclude from that repo.
I don't even see https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.3/ on reposync, is that a new repo?
No, it's just the testing repo generated by the sum of http://cbs.centos.org/repos/virt7-ovirt-common-testing/x86_64/os/ and http://cbs.centos.org/repos/virt7-ovirt-43-testing/x86_64/os/
https://copr-be.cloud.fedoraproject.org/results/mdbarroso/openvswitch/fedora... for Fedora?
If its needed for the project itself (check-patch) the project owner should update it in their automation/check-patch.fc28 file:
cat check-merged.repos.fc28 ovirt-snapshot-static,http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/$distro mdbarroso-python-ovsdbapp,https://copr-be.cloud.fedoraproject.org/results/mdbarroso/ovsdbapp/fedora-$r... tested,http://resources.ovirt.org/repos/ovirt/tested/master/rpm/$distro virt-preview,http://fedorapeople.org/groups/virt/virt-preview/fedora-$releasever/$basearc...
I've tried locally to revert patch [2] that added the 4.3 branch to the provider; it fixed this, but I think that's just masking the problem.
[0] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/conso... [1] - https://jenkins.ovirt.org/job/ovirt-provider-ovn_master_check-patch-el7-x86_... [2] - https://gerrit.ovirt.org/#/c/98565/
[1] https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/264/
On 19 Mar 2019, at 17:10, Anton Marchukov <amarchuk@redhat.com> wrote:
I retriggered. Will see.
On 19 Mar 2019, at 16:25, Miguel Duarte de Mora Barroso <mdbarroso@redhat.com> wrote:
https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
-- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA sbonazzo@redhat.com
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/4GWFMJTRWF6Y42...
-- EYAL EDRI
MANAGER RHV/CNV DEVOPS EMEA VIRTUALIZATION R&D
Red Hat EMEA TRIED. TESTED. TRUSTED. phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
-- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA sbonazzo@redhat.com
-- Anton Marchukov Associate Manager - RHV DevOps - Red Hat
participants (5)
-
Anton Marchukov -
Dan Kenigsberg -
Eyal Edri -
Miguel Duarte de Mora Barroso -
Sandro Bonazzola