Bug 988849

Note:  need to ignore comments in the file (lines prefixed with #)
Need to handle firewalld vs iptables

ovirt-host-deploy sets iptables rules specified by engine.

We are not ready for firewalld at host side.

(In reply to Alon Bar-Lev from comment #2)
> ovirt-host-deploy sets iptables rules specified by engine.
> 
> We are not ready for firewalld at host side.

Need to correct... ovirt-engine does not support firewalld but only iptables, and this is what it sends to ovirt-host-deploy (otopi).

otopi supports firewalld... but engine should use that feature.

http://gerrit.ovirt.org/17843

handles both iptables and firewalld

I am unsure how this change solves the problem.

As I wrote in comment#3, ovirt-engine does not support firewalld, it will configure machine using iptables.

In future, when ovirt-engine will support firewalld, it will configure firewalld during host-deploy, the plugin will be a simple registration notification, nothing more.

ovirt-node had firewalld support since F18, what was being done in F18 timeframe with ovirt-host-deploy to make it work?

I can open the ports that ovirt-host-deploy would do in the base image but the patch will work for other plugins that don't expect to manage firewalld/iptables.

Are you asking to revert back to just iptables or can we meet in the middle and open necessary ports?

(In reply to Joey Boggs from comment #6)
> ovirt-node had firewalld support since F18, what was being done in F18
> timeframe with ovirt-host-deploy to make it work?

There was no RFE for ovirt-engine as far as I know to support firewalld. The fact that ovirt-node reverted this as standalone component without synchronization is not correct.

> I can open the ports that ovirt-host-deploy would do in the base image but
> the patch will work for other plugins that don't expect to manage
> firewalld/iptables.

The ports to be opened are set by the engine and not by the deploy process. If we want to have it set by the node, we should modify the engine not to push iptables rules into the node.

But this will break 3.2 compatibility.

> Are you asking to revert back to just iptables or can we meet in the middle
> and open necessary ports?

I think we should revert back and have something working, then analyze the need of firewall throughout the project and provide a complete solution.

I would have the vdsm plugin or ovirt-host deploy include:

systemctl mask firewalld
systemctl stop firewalld
systemctl enable iptables.service
systemctl start iptables.service

I'm going to just revert the ovirt-node side since we will end up not opening the ports configured with firewalld ssh,libvirt, etc. So no work to be done within the vdsm-plugin unless its a safeguard.

patch updated

Test version:
ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34beta3.el6.iso
ovirt-node-3.0.4-1.0.el6.noarch

# cat /etc/ovirt-plugins.d/vdsm-plugin.firewall 
#ports and protocols that vdsm needs opened
54321,tcp

# iptables -L | grep 54321
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:54321 

The file /etc/ovirt-plugins.d/vdsm-plugin.firewall can list ports and protocols that vdsm needs opened. so the bug is fixed, change bug status to VERIFIED.

this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released