Created attachment 961645 [details] ovirt-engine-3.5/var/log/ovirt-engine/host-deploy log file Description of problem: Installing a host on el7 fails with yum syntax errors. While trying to install a host on el7 error occurred with yum syntax errors- the engine's error log is attached. after manually yum installing glusterfs on the host, the reinstallation completes successfully. (also vdsm was needed to be installed, I've opened another bug for it: https://bugzilla.redhat.com/show_bug.cgi?id=1168203 ) Version-Release number of selected component (if applicable): engine built from source with commit hash: 4d412660f9dcf2fbe057fc99058ba5d8d97520f1 otopi version: otopi-1.3.1-0.0.master.20141027.git34aedec.fc20.noarch otopi-java-1.3.1-0.0.master.20141027.git34aedec.fc20.noarch yum version on the host: # yum --version 3.4.3 Installed: rpm-4.11.1-16.el7.x86_64 at 2014-10-06 10:59 Built : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> at 2014-03-24 11:24 Committed: Panu Matilainen <pmatilai> at 2014-03-24 Installed: subscription-manager-1.10.14-8.el7_0.x86_64 at 2014-10-06 13:01 Built : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> at 2014-05-27 14:41 Committed: ckozak <ckozak> at 2014-05-27 Installed: yum-3.4.3-118.el7.noarch at 2014-10-06 10:59 Built : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> at 2014-04-15 13:54 Committed: James Antill <james.antill> at 2014-04-15 How reproducible: 100% at my host, didn't try on other hosts.. Steps to Reproduce: 1. add an el7 host to ovirt 2. 3. Actual results: fails with yum errors as described above & in the attached log Expected results: installation should succeed Additional info:
Why is this opened for host-deploy, please move it to package that is failing.
(In reply to Alon Bar-Lev from comment #1) > Why is this opened for host-deploy, please move it to package that is > failing. Alon - calling "yum install vdsm" and "yum install glusterfs" manually on the said host works. Attempting to deploy VDSM there from the engine fails with said errors: 2014-11-26 10:44:14 DEBUG otopi.plugins.otopi.packagers.yumpackager yumpackager.verbose:88 Yum Script sink: /var/tmp/rpm-tmp.mCnclO: line 1: syntax error near unexpected token `noreplace' /var/tmp/rpm-tmp.mCnclO: line 1: `/bin/systemctl try-restart rsyslog.service ;%config(noreplace) /etc/glusterfs/group-small-file-perf.example' warning: %post(glusterfs-3.6.0.5-1.el7.x86_64) scriptlet failed, exit status 2 Please advise which package this should be moved to?
(In reply to Allon Mureinik from comment #2) > (In reply to Alon Bar-Lev from comment #1) > > Why is this opened for host-deploy, please move it to package that is > > failing. > > Alon - calling "yum install vdsm" and "yum install glusterfs" manually on > the said host works. > Attempting to deploy VDSM there from the engine fails with said errors: > > 2014-11-26 10:44:14 DEBUG otopi.plugins.otopi.packagers.yumpackager > yumpackager.verbose:88 Yum Script sink: /var/tmp/rpm-tmp.mCnclO: line 1: > syntax error near unexpected token `noreplace' > /var/tmp/rpm-tmp.mCnclO: line 1: `/bin/systemctl try-restart rsyslog.service > ;%config(noreplace) /etc/glusterfs/group-small-file-perf.example' > warning: %post(glusterfs-3.6.0.5-1.el7.x86_64) scriptlet failed, exit status > 2 > > Please advise which package this should be moved to? it is not working, you just ignoring the warning of the scriptlets while host-deploy does not. please fix the package.
OK, so the error is coming form the package, not way host deploy is using yum - thanks. Moving to GlusterFS to investigate. GlusterFS guys - this issue is generated when installing glusterfs-3.6.0.5-1.el7.x86_64. We encountered it when running ovirt-host-deploy, but as comment 3 explains, this should be inconsequential.
glusterfs-3.6.0.5-1.el7.x86_64 comes from Red Hat Storage/RHEL, it is not a Gluster Community release.
glusterfs client on RHEL 7 is available in RH-Common channel. The channel has the latest client >= glusterfs-3.6.0.28-1.el7 Try to reproduce this bz with rh-common channel and close it accordingly.
Alright, I have changed the yum channels to common, and tried upgrading again from 3.4.0.65 to 3.6.0.29-2. it seems to work, the error didn't appear again. closing the bug.