This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 988075 - deploy fail if firewalld service cannot be started
deploy fail if firewalld service cannot be started
Status: CLOSED CURRENTRELEASE
Product: otopi
Classification: oVirt
Component: Plugins.network (Show other bugs)
master
Unspecified Unspecified
unspecified Severity high (vote)
: ---
: 1.1.0
Assigned To: Alon Bar-Lev
Pavel Stehlik
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-24 12:50 EDT by Pavel Stehlik
Modified: 2016-02-10 14:10 EST (History)
9 users (show)

See Also:
Fixed In Version: is7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-23 03:32:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
engine-ovirt.logs.tgz (8.99 KB, application/x-gzip)
2013-07-24 12:50 EDT, Pavel Stehlik
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 17302 None None None Never

  None (edit)
Description Pavel Stehlik 2013-07-24 12:50:27 EDT
Created attachment 777865 [details]
engine-ovirt.logs.tgz

Description of problem:
 When adding new host - Advanced Parameters - Automatically configure host firewall is NOT checked, however otopi installer is trying to configure it anyway.
Maybe matter of otopi, can't say where culprit is - insufficient log information. 

host-deploy.log
================
2013-07-24 18:10:09 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:446 execute-output: ('/bin/systemctl', 'start', 'firewalld.service') stderr:
Job for firewalld.service failed. See 'systemctl status firewalld.service' and 'journalctl -xn' for details.

2013-07-24 18:10:09 DEBUG otopi.context context._executeMethod:132 method exception
Traceback (most recent call last):
  File "/tmp/ovirt-rW1nPzPpM3/pythonlib/otopi/context.py", line 122, in _executeMethod
    method['method']()
  File "/tmp/ovirt-rW1nPzPpM3/otopi-plugins/otopi/network/firewalld.py", line 159, in _customization
    self._firewalld_version = self._get_firewalld_cmd_version()


Version-Release number of selected component (if applicable):
ovirt-engine-3.3.0-0.3.beta1.fc19.noarch

How reproducible:
100%

Steps to Reproduce:
1. disable/uninst firewalld on host
2. add host via webadmin & don't let configure firewall on host
3.

Actual results:


Expected results:


Additional info:
engine.log:
=================
2013-07-24 18:10:08,810 ERROR [org.ovirt.engine.core.utils.ssh.SSHDialog] (pool-6-thread-50) SSH error running command root@10.34.66.71:'umask 0077; MYTMP="$(mktemp -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; rm -fr "${MYTMP}" && mkdir "${MYTMP}" && tar --warning=no-timestamp -C "${MYTMP}" -x &&  "${MYTMP}"/setup DIALOG/dialect=str:machine DIALOG/customization=bool:True': java.io.IOException: Command returned failure code 1 during SSH session 'root@10.34.66.71'
        at org.ovirt.engine.core.utils.ssh.SSHClient.executeCommand(SSHClient.java:507) [utils.jar:]
        at org.ovirt.engine.core.utils.ssh.SSHDialog.executeCommand(SSHDialog.java:311) [utils.jar:]
        at org.ovirt.engine.core.bll.VdsDeploy.execute(VdsDeploy.java:1028) [bll.jar:]
        at org.ovirt.engine.core.bll.InstallVdsCommand.installHost(InstallVdsCommand.java:167) [bll.jar:]
        at org.ovirt.engine.core.bll.InstallVdsCommand.executeCommand(InstallVdsCommand.java:98) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1128) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1213) [bll.jar:]
Comment 1 Alon Bar-Lev 2013-07-24 14:15:25 EDT
Yes, this firewalld like other 'new' components is very hard to interact with... to query its version we must start it... and from what I see from this log, it fails to start.

I will just ignore firewalld if it fails to start.
Comment 2 Alon Bar-Lev 2013-07-24 14:17:02 EDT
On second thought... I am unsure we should even use firewalld if it is down.
Comment 3 Itamar Heim 2013-07-24 14:41:49 EDT
(In reply to Alon Bar-Lev from comment #2)
> On second thought... I am unsure we should even use firewalld if it is down.

should we care if its configured to start at next boot rather than only if currently running?
Comment 4 Alon Bar-Lev 2013-07-29 07:32:48 EDT
(In reply to Itamar Heim from comment #3)
> (In reply to Alon Bar-Lev from comment #2)
> > On second thought... I am unsure we should even use firewalld if it is down.
> 
> should we care if its configured to start at next boot rather than only if
> currently running?

In case of these dbus deamons (systemd, firewalld, ...), apart from the dependencies it has one side effect - if you do not have service running you cannot communicate with it. this approach is very unwise, as for example, you cannot configure firewalld during rpm installation...
Comment 5 Itamar Heim 2013-09-23 03:32:03 EDT
closing as this should be in 3.3 (doing so in bulk, so may be incorrect)

Note You need to log in before you can comment on or make changes to this bug.