Bug 1481718 - Ignore out-of-sync defaultRoute in clusterLevel < 4.1, since older hosts do not report it properly
Summary: Ignore out-of-sync defaultRoute in clusterLevel < 4.1, since older hosts do n...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 4.2.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ovirt-4.2.0
: 4.2.0
Assignee: eraviv
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On: 1506258 1507891
Blocks: 1200963
TreeView+ depends on / blocked
 
Reported: 2017-08-15 14:05 UTC by Michael Burman
Modified: 2017-12-20 11:29 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-12-20 11:29:23 UTC
oVirt Team: Network
Embargoed:
rule-engine: ovirt-4.2+
rule-engine: blocker+


Attachments (Terms of Use)
Logs (870.17 KB, application/x-gzip)
2017-08-15 14:05 UTC, Michael Burman
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 81916 0 None None None 2017-11-09 10:56:00 UTC

Description Michael Burman 2017-08-15 14:05:18 UTC
Created attachment 1313723 [details]
Logs

Description of problem:
Make sure to sync the management network when adding host version lower then < 4.1 to engine 4.2.

If adding a host to cluster level lower then < 4.1, the management network reported as out of sync, because the default route is true in the DC, but false on the host.

We didn't add support for the default route property on version lower then 4.1.
We should take care and ignore and sync the ovirtmgmt network in such cases.
If we try to sync it we will fail and network will remain as out of sync.

Version-Release number of selected component (if applicable):
4.2.0-0.0.master.20170814200319.git3da5f35.el7.centos
Host - vdsm-4.18.24-3.el7ev.x86_64

How reproducible:
100

Steps to Reproduce:
1. Add host 3.6/4.0 to engine 4.2

Actual results:
ovirtmgmt is out of sync

Expected results:
ovirtmgmt must be sync in add host operation

Comment 1 Dan Kenigsberg 2017-08-15 14:44:21 UTC
Until solving this bug, upgrade from ovirt-engine-4.1 to 4.2 makes all 3.6/4.0 become out-of-sync.

Comment 2 Michael Burman 2017-11-09 09:50:27 UTC
Hi Eitan, Dan

I don't see any patches attached to this bug and it's ON_QA, how come? please attach patches to this report.

Comment 3 Michael Burman 2017-11-09 11:47:22 UTC
Thanks Eitan, 

Dan, we can't test this bug and we are blocked. We can't add 3.6 and 4.0 hosts to engine 4.2, as it requires 'ovirt-host' package 

An error has occurred during installation of Host silver-vdsb.qa.lab.tlv.redhat.com: Failed to execute stage 'Setup validation': Cannot locate ovirt-host package, possible cause is incorrect channels.

I don't think that anyone planing to fix this for 3.6 and 4.0 hosts. 

Currently it was fixed for 4.2 upstream - BZ 1495854
Fixed for 4.1 upstream - BZ 1503124
Will be fixed for 4.1 downstream + 4.1 ngn downstream - BZ 1506262 and BZ 1506258

In the bottom line i'm blocked from testing this.

Comment 4 Michael Burman 2017-11-09 13:01:08 UTC
After speaking with Lukas from Infra team, we will need to wait for the fix of BZ 1506258 and BZ 1507891 and this should be tested only on 4.2 downstream engine and not 4.2 upstream.

Comment 5 Michael Burman 2017-11-30 11:50:40 UTC
Note for my self - 
4.z flow was verified with success after BZ 1506258 has been fixed.
Waiting for BZ 1507891 to be ON_QA to verify the 3.6 flow

Comment 6 Michael Burman 2017-12-13 08:22:22 UTC
Now when BZ 1507891 is ON_QA and ovirt-host package provided on 3.6 and 4.z versions this bug can be tested and verified.

Verified on - 4.2.0.2-0.1.el7

Comment 7 Sandro Bonazzola 2017-12-20 11:29:23 UTC
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.