Bug 1511013

Summary: 3.6 host install fails because of firewall type set to firewalld in 3.6 cluster
Product: [oVirt] ovirt-engine Reporter: Jiri Belka <jbelka>
Component: Backend.CoreAssignee: Ondra Machacek <omachace>
Status: CLOSED CURRENTRELEASE QA Contact: Jiri Belka <jbelka>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.2.0CC: bugs, danken, jbelka, mperina, ylavi
Target Milestone: ovirt-4.2.1Flags: rule-engine: ovirt-4.2+
Target Release: 4.2.1   
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-02-12 11:58:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jiri Belka 2017-11-08 14:14:18 UTC
Description of problem:

3.6 host is configured with firewalld as firewall type in 3.6 cluster on 4.2 env - thus it fails.

it seems it's some strange issue, i got this once from three attempts. imo it seems something related to ui, how it loads firewall type for 3.6 cluster (it is grey-disabled in 3.6 cluster).

engine=# select name,firewall_type from cluster;
  name   | firewall_type 
---------+---------------
 Default |             1
 36      |             0

2017-11-08 14:09:09,993+01 INFO  [org.ovirt.engine.core.common.utils.ansible.AnsibleExecutor] (EE-ManagedTh
readFactory-engine-Thread-52278) [3adc0bcd] Executing Ansible command: /usr/bin/ansible-playbook --private-
key=/etc/pki/ovirt-engine/keys/engine_id_rsa --inventory=/tmp/ansible-inventory2012835916277640297 --extra-
vars=host_deploy_cluster_version=3.6 --extra-vars=host_deploy_gluster_enabled=false --extra-vars=host_deplo
y_virt_enabled=true --extra-vars=host_deploy_vdsm_port=54321 --extra-vars=host_deploy_override_firewall=tru
e --extra-vars=host_deploy_firewall_type=FIREWALLD --extra-vars=ansible_port=22 --extra-vars=host_deploy_po
st_tasks=/etc/ovirt-engine/../ovirt-ansible-roles/ovirt-host-deploy-post-tasks.yml --extra-vars=host_deploy
_ovn_tunneling_network=10.37.138.106 --extra-vars=host_deploy_ovn_central=null /usr/share/ovirt-engine/../o
virt-ansible-roles/playbooks/ovirt-host-deploy.yml

...
TASK [ovirt-host-deploy-firewalld : Check if VDSM version is supported for FirewallD] ***
fatal: [10.37.138.106]: FAILED! => {"changed": false, "failed": true, "msg": "VDSM version 4.17.43 is not supported for FirewallD."}

Version-Release number of selected component (if applicable):
ovirt-engine-webadmin-portal-4.2.0-0.4.master.el7.noarch

How reproducible:
1 in 1

Steps to Reproduce:
1. create 3.6 dc/cl
2. add 3.6 host
3.

Actual results:
install failed as it wanted to set firewalld on 3.6 host

Expected results:
for 3.6 cluster it should be _always_ iptables

Additional info:

Comment 2 Martin Perina 2017-11-21 11:26:52 UTC
Is still reproducible in latest builds?

Comment 3 Jiri Belka 2017-12-07 09:54:36 UTC
(In reply to Martin Perina from comment #2)
> Is still reproducible in latest builds?

Yes. Host EL 7.3 EUS with vdsm-4.17.43-1.el7ev.noarch and rhvm-4.2.0-0.5.master.el7.noarch.

Comment 4 Red Hat Bugzilla Rules Engine 2017-12-07 09:54:42 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 5 Jiri Belka 2017-12-08 09:57:01 UTC
yesterday with 4.2, it seems to related to Guide Me procedure:

engine=# select name,firewall_type from cluster;
  name   | firewall_type 
---------+---------------
 Default |             1
 3_6     |             1
(2 rows)

Comment 6 Jiri Belka 2018-01-16 10:44:35 UTC
ok, ovirt-engine-webadmin-portal-4.2.1.1-0.1.el7.noarch

3.6 cluster is iptables based and 3.6 host added from Guide Me is Up.

Comment 7 Sandro Bonazzola 2018-02-12 11:58:09 UTC
This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.1 release, it has been closed with a resolution of CURRENT RELEASE.

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