Description of problem: Currently VDSM (or Engine?) requires iptables and can not interact with firewalld. To cope with the future it would be nice if VDSM could also handle firewalld.
fabain - i assume you mean as part of bootstrap alon - i thought we do handle firewalld?
(In reply to Itamar Heim from comment #1) > alon - i thought we do handle firewalld? Can you please explain how you dedicated that? from what? engine has still hard coded iptables rules within its database.
from confusing the fact it was added to the engine installer vs. the host side...
I would like to avoid passing this to someone else which may not be involved at all so I would like to understand who is the right person for assigning this bug. The issue here is not in the setup / packaging area: engine-setup already support firewalld also for AIO installations. The issue here is that when you add an host, you can configure only iptables on that host because the engine haas still hardcoded iptables rules within its database. The SDK only allows to override_iptables because of that. Involved packages here are: - ovirt-engine-sdk-python - ovirt-host-deploy - ovirt-engine-dbscripts? - ovirt-engine-backend? - vdsm (./vds_bootstrap/vds_bootstrap.py: references iptables rules) and probably more. I think this bug can be used as tracker for "RFE: add FirewallD support to oVirt" and a few bugs should be opened against each component affected.
Alon, I tought we already support that for Fedora ? If this is not the case than please move the target release for 3.5
(In reply to Barak from comment #6) > Alon, I tought we already support that for Fedora ? > If this is not the case than please move the target release for 3.5 we do not support firewalld as engine does not support it. it is a change in engine and the way it holds the rules and push then to host.
This is an automated message. This Bugzilla report has been opened on a version which is not maintained anymore. Please check if this bug is still relevant in oVirt 3.5.4. If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution) If it's an RFE please update the version to 4.0 if still relevant.
This is an automated message. This Bugzilla report has been opened on a version which is not maintained anymore. Please check if this bug is still relevant in oVirt 3.5.4 and reopen if still an issue.
rfes should not be closed using this approach.
Could we get this targeted for 3.6.z? Currently I can not add a default and fresh CentOS 7 installation to Engine, because firewalld keeps running and prevents Engine<->vdsm communication.
(In reply to Fabian Deutsch from comment #11) > Could we get this targeted for 3.6.z? > > Currently I can not add a default and fresh CentOS 7 installation to Engine, > because firewalld keeps running and prevents Engine<->vdsm communication. no, it has impact on engine configuration as well. firewalld should be stopped when iptables is being used. @plugin.event( stage=plugin.Stages.STAGE_CLOSEUP, condition=lambda self: self._enabled, ) def _closeup(self): # We would like to avoid conflict if self.services.exists('firewalld'): self.services.startup('firewalld', False) self.services.state('firewalld', False) self.services.startup('iptables', True) self.services.state('iptables', False) self.services.state('iptables', True) if not, please open a bug with full logs.
*** Bug 1304445 has been marked as a duplicate of this bug. ***
What's the status? I see this: - engine, firewalld running - host, firewalld not running - she host, firewalld not running
We can change the firewalld configuration on engine-setup as far as I know. Sandro? As for the hosts, I guess Sandro can help as well, as I'm not sure what is being done in host-deploy with regards to firewalld.
(In reply to Oved Ourfali from comment #16) > We can change the firewalld configuration on engine-setup as far as I know. > Sandro? Indeed. > As for the hosts, I guess Sandro can help as well, as I'm not sure what is > being done in host-deploy with regards to firewalld. Nothing. And also nothing with iptables. All the functionality of configuring iptables is directed from the engine during host-deploy, but interacts with otopi functionality directly - nothing in host-deploy. otopi already supports firewalld, and I think its support is more-or-less complete - engine-setup already uses it successfully. So what needs to be done is basically: 1. Design. Currently, engine has vdc_options IPTablesConfig, IPTablesConfigForGluster, IPTablesConfigForVirt and IPTablesConfigSiteCustom. In firewalld, configuration is not snippets of /etc/sysconfig/iptables, so above would not nicely translate. In firewalld simple configuration you add service definitions, then add these services to zones. So we might want per each of above, a list of services we want to enable (and/or disable), or something like that. 2. Make the engine side of the host-deploy process send relevant commands so that otopi configures firewalld as needed. This is done by setting otopi env firewalldEnable=bool:True and NETWORK_FIREWALLD_SERVICE/some-service-name=service-xml-content, where "some-service-name" is the service name and "service-xml-content" is the content of the service's xml file. It enables the service on all the active zones. You can check engine-setup logs to see how it looks like. It's also briefly documented in otopi's README.environment file. Of course - above is only the host-deploy/otopi part. It does not include ui etc., including questions like do we want to allow the user to choose between iptables/firewalld/none etc - replace the current checkbox or extend it. It also relies on the relevant packages already being installed on the host - if we want to make this dynamic, that's more complex - especially if/when we want to support hosts that do not have firewalld packaged for them (e.g. Debian) - then we can't just tell the host "install firewalld".
Didi already provided the needed info
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.
ok, ovirt-engine-4.2.0-0.0.master.20171012160334.git6fb4578.el7.centos.noarch
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.