Created attachment 1359160 [details] host deploy log Description of problem: Clusters lower than 4.2 should be by default set with 'iptables' and not 'firewalld' in the Firewall Type. The default firewall type for new clusters in rhv 4.2 is 'firewalld' type, but vdsm lower than 4.2 isn't supported with firewallD, only iptables, which means that add host will fail. TASK [ovirt-host-deploy-firewalld : Check if VDSM version is supported for FirewallD] *** fatal: [orchid-vds2.qa.lab.tlv.redhat.com]: FAILED! => {"changed": false, "failed": true, "msg": "VDSM version 4.19.40 is not supported for FirewallD."} Version-Release number of selected component (if applicable): vdsm-4.19.40-1.el7ev.x86_64 Steps to Reproduce: 1. Create new DC+cluster 4.1 in rhv 4.2(use default settings for cluster) 2. Try to add host with vdsm-4.19.40-1.el7ev.x86_64 Actual results: Host orchid-vds2.qa.lab.tlv.redhat.com installation failed. Failed to execute Ansible host-deploy role. VDSM version 4.19.40 is not supported for FirewallD, but the default firewall type for new clusters is firewalld and not iptables. If you change the type to 'iptables' then the add host works. Expected results: The default firewall type for clusters lower than <4.2 should be 'iptables' and not 'firewalld'.
1. FirewallD is engine feature not a cluster level one, which means that it does not depend on cluster level but VDSM version installed on the host 2. When 4.2 is out, all new host will be installed with VDSM from 4.2 (which is fully compatible with 3.6+ cluster levels), which means that all new 4.0 clusters should have be default firewalld enabled 3. We have decided to set firewalld as default for all newly created clusters in 4.2 engine, only new 3.6 clusters will have iptables set by default. So if admins wants to use iptables instead, they can change it in Cluster Detail and Reinstall host. 4. iptables support has been deprecated in 4.2 and will be completely removed in 4.3 (see BZ1490866) Based on above closing as not a bug.
(In reply to Martin Perina from comment #1) > 1. FirewallD is engine feature not a cluster level one, which means that it > does not depend on cluster level but VDSM version installed on the host > > 2. When 4.2 is out, all new host will be installed with VDSM from 4.2 > (which is fully compatible with 3.6+ cluster levels), which means that all > new 4.0 clusters should have be default firewalld enabled > > 3. We have decided to set firewalld as default for all newly created > clusters in 4.2 engine, only new 3.6 clusters will have iptables set by > default. So if admins wants to use iptables instead, they can change it in > Cluster Detail and Reinstall host. > > 4. iptables support has been deprecated in 4.2 and will be completely > removed in 4.3 (see BZ1490866) > > > Based on above closing as not a bug. Hi Martin, Ok, but i'm still confused here, please help me to understand - 1) Yes it is an engine feature and if on the vdsm side firewalld is not supported for versions lower than 4.2, then you need to adjust the engine accordingly, just like you decided for 3.6 cluster, the same should be done for clusters 4.0 and 4.1, there is no difference between them for this matter. The default for 4.0 and 4.1 should be the same as for 3.6 cluster, this is just obvious. 2) Can you please explain why admin will add 4.2 vdsm to lower cluster? We do allow to create new DCs and clusters 3.6/4.0/4.1, which means we do expect that new hosts will be added to this clusters, and not 4.2 vdsm, but lower. 3) If we do expect that all new hosts will be installed only with 4.2 vdsm, then why we have the option to create new DCs and clusters with lower versions? 4) In the bottom line, the same fix you done for clusters 3.6, should be done for 4.0 and 4.1, the default should be 'iptables' for all, except 4.2. This is very simple: vdsm 3.6,4.0,4.1 - iptables, then the default cluster type must be > iptables vdsm 4.2 - firewalld, then the default cluster type must be > firewalld From my point of view, this is a bug and should be fixed.
(In reply to Michael Burman from comment #2) > (In reply to Martin Perina from comment #1) > > 1. FirewallD is engine feature not a cluster level one, which means that it > > does not depend on cluster level but VDSM version installed on the host > > > > 2. When 4.2 is out, all new host will be installed with VDSM from 4.2 > > (which is fully compatible with 3.6+ cluster levels), which means that all > > new 4.0 clusters should have be default firewalld enabled > > > > 3. We have decided to set firewalld as default for all newly created > > clusters in 4.2 engine, only new 3.6 clusters will have iptables set by > > default. So if admins wants to use iptables instead, they can change it in > > Cluster Detail and Reinstall host. > > > > 4. iptables support has been deprecated in 4.2 and will be completely > > removed in 4.3 (see BZ1490866) > > > > > > Based on above closing as not a bug. > > Hi Martin, > > Ok, but i'm still confused here, please help me to understand - > > 1) Yes it is an engine feature and if on the vdsm side firewalld is not > supported for versions lower than 4.2, then you need to adjust the engine > accordingly, just like you decided for 3.6 cluster, the same should be done > for clusters 4.0 and 4.1, there is no difference between them for this > matter. The default for 4.0 and 4.1 should be the same as for 3.6 cluster, > this is just obvious. No, it's different. 3.x and 4.x hosts are on different channels, so while you are able to 3.6 host into 3.6 cluster level, it's very hard to add 4.0/4.1 host into 4.0/4.1 cluster level, because you will always install highest available version. Similar situation is on upstream, once 4.2 is out and you upgrade engine to it, 4.1 hosts/engine are no longer supported. > > 2) Can you please explain why admin will add 4.2 vdsm to lower cluster? > We do allow to create new DCs and clusters 3.6/4.0/4.1, which means we do > expect that new hosts will be added to this clusters, and not 4.2 vdsm, but > lower. Because 4.2 host is backward compatible, so it can easily act as 4.0/4.1 host and also it's the only version with updates. 3.6 is a bit special, because we still have 3.6 ELS support for that. > > 3) If we do expect that all new hosts will be installed only with 4.2 vdsm, > then why we have the option to create new DCs and clusters with lower > versions? Cluster level is about cluster wide features, so having older cluster levels in your setup is fine (although you will receive periodical warnings that you should upgrade), but when you already upgrade to 4.2 why you would like to create older clusters/DCs? > > 4) In the bottom line, the same fix you done for clusters 3.6, should be > done for 4.0 and 4.1, the default should be 'iptables' for all, except 4.2. > This is very simple: > vdsm 3.6,4.0,4.1 - iptables, then the default cluster type must be > iptables > vdsm 4.2 - firewalld, then the default cluster type must be > firewalld No, 3.6 is special because of ELS support. That's why we don't allow to set firewalld and also hopefully 3.6 cluster level will be finally removed in 4.3, so everybody have to upgrade. 4.0/4.1 are just minor versions and as such you should always upgrade as soon as possible, otherwise there was no meaning in upgrading to 4.2 > > From my point of view, this is a bug and should be fixed. I think it's a feature and not a bug, but forwarding to Moran to say final word.
*** Bug 1539729 has been marked as a duplicate of this bug. ***
*** Bug 1656835 has been marked as a duplicate of this bug. ***
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days