Description of problem: After restoring backup of 3.6 engine from EL6 on cleanly installed EL7 with 3.6 engine rpms, engine-setup fails with error: Failed to execute stage 'Setup validation': Firewall manager iptables is not available (This issue appears only on restore and subsequent engine-setup on clean EL7, as I did not have this issue while doing in-place migration via redhat-upgrade-tool.) /sbin/iptables is of course available. Version-Release number of selected component (if applicable): ovirt-engine-setup-base-3.6.4.1-1.el7.centos.noarch How reproducible: 100% Steps to Reproduce: 1. install 3.6 engine on EL6 2. engine-backup to backup everything 3. yum install ovirt-engine 4. engine-backup to restore everything 5. engine-setup Actual results: Failed to execute stage 'Setup validation': Firewall manager iptables is not available Expected results: should work Additional info: modifying 'OVESETUP_CONFIG/firewallManager' to 'none:None' and accepting 'firewalld' as value for this question in next engine-setup run, makes the setup procedure pass this step.
Workaround: Before engine-setup: yum install iptables-services systemctl stop firewalld systemctl disable firewalld systemctl start iptables systemctl enable iptables Or (that's not officially supported currently, see also bug 1097857 comment 1 and the very long discussion on the patch for it https://gerrit.ovirt.org/20737): engine-setup --offline --otopi-environment='OVESETUP_CONFIG/firewallManager=str:firewalld' For a solution, perhaps one of: 1. Require iptables-services (not sure we want that, but it's easiest) 2. Do nothing, only document that for migration. 3. Do something in 'engine-backup --mode=restore' - either just a note, or also install the package (I don't like this one) Sandro - what do you think?
Thinking about this again, perhaps: If selected firewall manager is 'iptables', add 'iptables-services' to PACKAGES_UPGRADE_LIST . This should work equally well for: 1. Normal setup with an answer file choosing iptables 2. Restore from a backup which had iptables Also need to check and fix as needed what happens if firewalld was already enabled/started - IIRC I noticed that it's now different from what it was when we developed this functionality (around fedora 18 or so), where starting one of iptables/firewalld stopped the other.
Eventually decided to not install iptables-services, just notify the user if iptables service is missing.
Can this be merge to 3.6 ? Otherwise migration from 3.6 EL6 to 3.6 EL7 does fail.
(In reply to Jiri Belka from comment #5) > Can this be merge to 3.6 ? Otherwise migration from 3.6 EL6 to 3.6 EL7 does > fail. It's a simple cherry-pick, no objection from my side. Not sure it's that important though - it affects upstream for a long time now, as we shipped there an engine for both el6 and el7 already in 3.5. I never heard a request for such a migration, and expect almost all people will migrate only when required (in 4.0), and the few that did care, handled this manually somehow (by installing iptables-service, saying 'no' to 'configure firewall?', whatever).
(In reply to Yedidyah Bar David from comment #6) > (In reply to Jiri Belka from comment #5) > > Can this be merge to 3.6 ? Otherwise migration from 3.6 EL6 to 3.6 EL7 does > > fail. > > It's a simple cherry-pick, no objection from my side. Not sure it's that > important though - it affects upstream for a long time now, as we shipped > there an engine for both el6 and el7 already in 3.5. I never heard a request > for such a migration, and expect almost all people will migrate only when > required (in 4.0), and the few that did care, handled this manually somehow > (by installing iptables-service, saying 'no' to 'configure firewall?', > whatever). Let's do this cherry pick cause I expect people to need it after we announce dropping support from el6 for the engine.
This bug has been moved ON_QA for 4.0 beta, then moved to 3.6.7 without changing state. Moving back to POST state so we can see that the cherry-pick has not been done.
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.
Sandro, it was already backported to 3.6 in bug 1332088.
This one has IMO bad target milestone set, it is clear this BZ is about restoring 3.6 backup on 4.0 and then running engine-setup. This flow was working fine many times for me with 4.0.0-10 build.
Can you please retest the flow of 3.6 el6 to 3.6 el7 and confirm this is working?
(In reply to Yaniv Dary from comment #12) > Can you please retest the flow of 3.6 el6 to 3.6 el7 and confirm this is > working? works ok on 3.6 el6 -> 3.6 el7 ovirt-engine-setup-base-3.6.6.2-1.el7.centos.noarch ovirt-engine-tools-backup-3.6.6.2-1.el7.centos.noarch
Sandro, can you please communicate that to the community for general use?
(In reply to Yaniv Dary from comment #14) > Sandro, can you please communicate that to the community for general use? http://lists.ovirt.org/pipermail/users/2016-July/041184.html