Bug 1323201
Summary: | [migration 3.6 el6 - 3.6 el7] Failed to execute stage 'Setup validation': Firewall manager iptables is not available | |||
---|---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Jiri Belka <jbelka> | |
Component: | Setup.EngineCommon | Assignee: | Yedidyah Bar David <didi> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Jiri Belka <jbelka> | |
Severity: | medium | Docs Contact: | ||
Priority: | medium | |||
Version: | 3.6.5 | CC: | bugs, dfediuck, didi, jbelka, sbonazzo, ylavi | |
Target Milestone: | ovirt-3.6.7 | Flags: | rule-engine:
ovirt-3.6.z+
rule-engine: exception+ rule-engine: planning_ack+ sbonazzo: devel_ack+ pnovotny: testing_ack+ |
|
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
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.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1332088 (view as bug list) | Environment: | ||
Last Closed: | 2016-06-02 14:06:48 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | Integration | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1318580, 1332088, 1332463 |
Description
Jiri Belka
2016-04-01 14:03:29 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? 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 |