Bug 1323201 - [migration 3.6 el6 - 3.6 el7] Failed to execute stage 'Setup validation': Firewall manager iptables is not available
Summary: [migration 3.6 el6 - 3.6 el7] Failed to execute stage 'Setup validation': Fir...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Setup.EngineCommon
Version: 3.6.5
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-3.6.7
: ---
Assignee: Yedidyah Bar David
QA Contact: Jiri Belka
URL:
Whiteboard:
Depends On:
Blocks: 1318580 1332088 1332463
TreeView+ depends on / blocked
 
Reported: 2016-04-01 14:03 UTC by Jiri Belka
Modified: 2017-05-11 09:26 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: When running engine-setup, as part of migration from 3.6/el6 to 4.0/el7, if the backed up engine was configured to automatically configure iptables, and the package 'iptables-services' was not installed on the target el7 machine, and the user accepted the choice to automatically configure the firewall, engine-setup failed. Consequence: It was not possible to finish the migration process without some manual action. Fix: engine-setup was changed to not fail in this case. Instead: 1. If the package iptables-services is installed prior to running engine-setup, it will work as expected. 2. If iptables-services is not installed, a warning will be issued. 3. If only firewalld is installed and active (up), it will be selected automatically. 4. If firewalld is installed but not active, the user will be prompted to choose it. The user will be prompted, and have to type in an answer, even if firewalld is the only option, to help prevent breaking non-standard/manual/etc iptables/firewall setups. All of the above applies, as before, only if the user accepts to automatically configure the firewall. Result: engine-setup, and the migration process, finish successfully, with a firewall manager configured, if possible and selected.
Clone Of:
: 1332088 (view as bug list)
Environment:
Last Closed: 2016-06-02 14:06:48 UTC
oVirt Team: Integration
Embargoed:
rule-engine: ovirt-3.6.z+
rule-engine: exception+
rule-engine: planning_ack+
sbonazzo: devel_ack+
pnovotny: testing_ack+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 56020 0 master MERGED packaging: setup: Reset firewall manager if not available 2016-04-13 08:12:50 UTC
oVirt gerrit 56021 0 master ABANDONED packaging: setup: Install package iptables-sevices if needed 2016-04-12 09:27:15 UTC

Description Jiri Belka 2016-04-01 14:03:29 UTC 
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.
Comment 2 Yedidyah Bar David 2016-04-07 14:55:36 UTC 
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?
Comment 3 Yedidyah Bar David 2016-04-11 06:29:14 UTC 
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.
Comment 4 Yedidyah Bar David 2016-04-12 13:54:18 UTC 
Eventually decided to not install iptables-services, just notify the user if iptables service is missing.
Comment 5 Jiri Belka 2016-04-25 16:32:15 UTC 
Can this be merge to 3.6 ? Otherwise migration from 3.6 EL6 to 3.6 EL7 does fail.
Comment 6 Yedidyah Bar David 2016-05-01 06:44:34 UTC 
(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).
Comment 7 Yaniv Lavi 2016-05-31 07:19:50 UTC 
(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.
Comment 8 Sandro Bonazzola 2016-06-01 05:52:37 UTC 
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.
Comment 9 Red Hat Bugzilla Rules Engine 2016-06-01 06:26:35 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 10 Yedidyah Bar David 2016-06-01 06:53:15 UTC 
Sandro, it was already backported to 3.6 in bug 1332088.
Comment 11 Jiri Belka 2016-06-01 09:57:13 UTC 
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.
Comment 12 Yaniv Lavi 2016-06-02 08:52:46 UTC 
Can you please retest the flow of 3.6 el6 to 3.6 el7 and confirm this is working?
Comment 13 Jiri Belka 2016-06-02 12:23:19 UTC 
(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
Comment 14 Yaniv Lavi 2016-06-02 14:06:48 UTC 
Sandro, can you please communicate that to the community for general use?
Comment 15 Sandro Bonazzola 2016-07-19 09:35:48 UTC 
(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
Note You need to log in before you can comment on or make changes to this bug.