Bug 1563653
Summary: | Adding a 4.1 RHVH host to a 4.2 engine fails | ||
---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Yuval Turgeman <yturgema> |
Component: | Host-Deploy | Assignee: | bugs <bugs> |
Status: | CLOSED NOTABUG | QA Contact: | Meni Yakove <myakove> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.2.2 | CC: | bugs, danken, dfediuck, didi, mperina, sabose, sradco, yturgema |
Target Milestone: | ovirt-4.2.3 | Keywords: | Regression |
Target Release: | --- | Flags: | rule-engine:
ovirt-4.2+
rule-engine: blocker+ |
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-04-05 06:53:44 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Yuval Turgeman
2018-04-04 12:01:35 UTC
Changing components, since we're trying to track deps for this in ovirt-host now, to have a unified place for all oVirt dependencies. Dan, do we really need to enforce ovirt-provider-ovn-driver on 4.1 hosts? Sahina, please check 3.6 hosts can still be added too, I've the feeling this may impact 3.6 hosts for RHGS if we still need to support them. This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP. Moved to engine component, since this is a regression introduced in the ansible post-deploy code AFAIK OVN shouldn't be configured for hosts in clusters with level 4.1 and below: https://github.com/oVirt/ovirt-engine/blob/master/packaging/playbooks/roles/ovirt-provider-ovn-driver/tasks/main.yml#L27 Could you please add engine logs? Managed to get around this, cluster level was indeed wrong. But I hit a different issue: 2018-04-04 09:48:13,139 p=2560 u=ovirt | TASK [ovirt-host-deploy-firewalld : Check if VDSM version is supported for FirewallD] *** 2018-04-04 09:48:13,171 p=2560 u=ovirt | fatal: [192.168.122.174]: FAILED! => { "changed": false } MSG: VDSM version 4.19.51 is not supported for FirewallD. Is that covered in a different bug ? (In reply to Yuval Turgeman from comment #6) > VDSM version 4.19.51 is not supported for FirewallD. > > Is that covered in a different bug ? probably yes, though similar. to which cluster level is this host added? if it is cluster of level 4.2, this is not a bug - a 4.1 host cannot be added to it. if, however, this is a new cluster, or a 4.1 cluster, we'd need to fix both bugs (requiring of ovn driver and FirewallD) Ovn rpm issue encountered in a 4.2 cluster, Firewalld issue encountered in cluster level 4.1 FirewallD works as expected, it's not bound to cluster level, but to the VDSM version on the host. So if all your hosts contains VDSM from 4.2, you can have firewalld enabled even though cluster level is 4.1 (In reply to Martin Perina from comment #9) > FirewallD works as expected, it's not bound to cluster level, but to the > VDSM version on the host. So if all your hosts contains VDSM from 4.2, you > can have firewalld enabled even though cluster level is 4.1 So RHVH 4.1 with firewalld enabled can't be added to a 4.2 engine even if the cluster level is 4.1 ? (In reply to Yuval Turgeman from comment #10) > (In reply to Martin Perina from comment #9) > > FirewallD works as expected, it's not bound to cluster level, but to the > > VDSM version on the host. So if all your hosts contains VDSM from 4.2, you > > can have firewalld enabled even though cluster level is 4.1 > > So RHVH 4.1 with firewalld enabled can't be added to a 4.2 engine even if > the cluster level is 4.1 ? Correct, firewalld works only with RHVH 4.2. If you want to add RHVH 3.6/4.0/4.1 to engine 4.2, then the cluster needs to be set to iptables Got it, it works now, I guess we can close this - it would have been nice if the default firewall type would change to iptables if the user selects a cluster level < 4.2. Anyway, sorry for the noise. Closing as per comment #12 |