Description of problem: Cannot install ovirt-log-collector on Fedora 20. # cat /etc/fedora-release Fedora release 20 (Heisenbug) Repos ======== Fedora 20 - x86_64 Nightly builds of the oVirt project Fedora 20 - x86_64 - Updates # yum install ovirt-log-collector -y Resolving Dependencies --> Running transaction check ---> Package ovirt-log-collector.noarch 0:3.4.0-0.0.master.20131115.git6ae1eca.fc20 will be installed --> Processing Dependency: python-dateutil for package: ovirt-log-collector-3.4.0-0.0.master.20131115.git6ae1eca.fc20.noarch --> Processing Dependency: ovirt-engine-lib for package: ovirt-log-collector-3.4.0-0.0.master.20131115.git6ae1eca.fc20.noarch --> Running transaction check ---> Package ovirt-engine-lib.noarch 0:3.4.0-0.2.master.20131129075935.git3f58634.fc20 will be installed --> Processing Dependency: python-daemon for package: ovirt-engine-lib-3.4.0-0.2.master.20131129075935.git3f58634.fc20.noarch ---> Package python-dateutil.noarch 0:1.5-7.fc20 will be installed --> Running transaction check ---> Package python-daemon.noarch 0:1.6-5.fc20 will be installed --> Processing Dependency: python-lockfile for package: python-daemon-1.6-5.fc20.noarch --> Running transaction check ---> Package python-lockfile.noarch 1:0.9.1-5.fc20 will be installed --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================================================================================= Package Arch Version Repository Size ======================================================================================================================================================================= Installing: ovirt-log-collector noarch 3.4.0-0.0.master.20131115.git6ae1eca.fc20 ovirt-nightly 49 k Installing for dependencies: ovirt-engine-lib noarch 3.4.0-0.2.master.20131129075935.git3f58634.fc20 ovirt-nightly 18 k python-daemon noarch 1.6-5.fc20 fedora 27 k python-dateutil noarch 1.5-7.fc20 fedora 85 k python-lockfile noarch 1:0.9.1-5.fc20 fedora 28 k Transaction Summary ======================================================================================================================================================================= Install 1 Package (+4 Dependent packages) Total size: 207 k Installed size: 694 k Downloading packages: Running transaction check Running transaction test Transaction check error: file /usr/lib/python2.7/site-packages/sos/plugins/postgresql.py from install of ovirt-log-collector-3.4.0-0.0.master.20131115.git6ae1eca.fc20.noarch conflicts with file from package sos-3.0-3.fc20.noarch file /usr/lib/python2.7/site-packages/sos/plugins/postgresql.pyc from install of ovirt-log-collector-3.4.0-0.0.master.20131115.git6ae1eca.fc20.noarch conflicts with file from package sos-3.0-3.fc20.noarch file /usr/lib/python2.7/site-packages/sos/plugins/postgresql.pyo from install of ovirt-log-collector-3.4.0-0.0.master.20131115.git6ae1eca.fc20.noarch conflicts with file from package sos-3.0-3.fc20.noarch
sos-3 changed API so our plugins don't work anymore. Additionally we've naming conflict between our own plugins and sos project plugins. We need to keep also compatibility with sos-2 for CentOS and RHEL 6. Keith, what do you think about this?
(In reply to Sandro Bonazzola from comment #1) > sos-3 changed API so our plugins don't work anymore. > Additionally we've naming conflict between our own plugins and sos project > plugins. > We need to keep also compatibility with sos-2 for CentOS and RHEL 6. > > Keith, what do you think about this? Sandro, Bryn took my postgres plug-in[1] and added it to SoS upstream[2] a while back. Originally, it was supposed to be renamed to psql.py upstream so that it wouldn't conflict with the one shipped with the LC. This would have allowed the LC to exist happily until the plug-in arrived in RHEL 6 at which point we could simply kill the one shipped with the LC and prefer the one shipped with SoS. For whatever reason, it didn't happen this way and my plug-in was pushed to SoS master as postgresql.py which clearly conflicts with [3]. As a remedy for upstream, I'd suggest yanking postgresql.py from oVirt and preferring the SoS one. They are the same. For downstream, you'll have to wait until BMR pulls it in and then carefully coordinate a LC release with a SoS release; otherwise, one of two things will happen: - User can't install/update RHEV - User can't install/update SoS Bryn, Can you give us a heads up as to when you think postgresql.py will arrive in the EL6 stream? Keith [1] https://github.com/sosreport/sosreport/pull/59 [2] https://github.com/sosreport/sosreport/blob/master/sos/plugins/postgresql.py [3] http://gerrit.ovirt.org/gitweb?p=ovirt-log-collector.git;a=tree;f=src/sos/plugins;h=0b3c4d3cb53a3bc69fea45f73b7393fb5f1cc922;hb=HEAD
Jesse committed the 'postgresql' module on master in his "giant refactoring commit": commit 6ea48cbbc85d007dfefd1f254db66ff2e0a9cec5 Author: Jesse Jaggars <jhjaggars> Date: Wed Dec 14 16:05:59 2011 -0600 Major updates to most of SoSReport The request I had to rename the plugin was only for the RHEL6 branch, which was done: commit 04f3b2f6068e3518dccf00a5d98ae07784fb3c88 Author: Bryn M. Reeves <bmr> Date: Wed Jan 9 14:45:04 2013 +0000 Rename psql as pgsql in rhel-6 Rename the PostgreSQL module to "pgsql" in the rhel-6 branch as suggested in bugzilla. Resolves: bz852049 There are no plans to rename this back to postgresql at this time for RHEL6.
(In reply to Bryn M. Reeves from comment #3) > Jesse committed the 'postgresql' module on master in his "giant refactoring > commit": > > commit 6ea48cbbc85d007dfefd1f254db66ff2e0a9cec5 > Author: Jesse Jaggars <jhjaggars> > Date: Wed Dec 14 16:05:59 2011 -0600 > > Major updates to most of SoSReport > > The request I had to rename the plugin was only for the RHEL6 branch, which > was done: > > commit 04f3b2f6068e3518dccf00a5d98ae07784fb3c88 > Author: Bryn M. Reeves <bmr> > Date: Wed Jan 9 14:45:04 2013 +0000 > > Rename psql as pgsql in rhel-6 > > Rename the PostgreSQL module to "pgsql" in the rhel-6 branch as > suggested in bugzilla. > > Resolves: bz852049 > > There are no plans to rename this back to postgresql at this time for RHEL6. Does it make sense to rename the upstream postgresql.py to pgsql.py so that we can get consistency?
temporary workaround: just remove sos and install sos from f19 repository
I'm pushing upstream both the plugins, we'll probably provide updated builds of sos for Fedora 20 until Fedora will deliver it.
Re-targeted to 3.5.0. We're now shipping sos-3.1 with our plugins: http://resources.ovirt.org/releases/nightly/rpm/Fedora/20/noarch/sos-3.1-1.fc20.ovirt.noarch.rpm but the ovirt-engine plugin has not yet been accepted upstream.
*** Bug 1063973 has been marked as a duplicate of this bug. ***
Reopened, since proposed solution won't work on Gentoo in the following scenario: - sos-2 installed - install log-collector - upgrade sos to 3.x this will cause file conflict during the upgrade on postgresql module. Need to rename the postgresql module also for sos-2.
Not sure what I can do about a Gentoo packaging problem in a Fedora bugzilla? Maybe this should be filed upstream instead? If nothing else if Gentoo are including ebuilds for sos in portage then it would make sense to add policy and tagging classes for the distribution. > this will cause file conflict during the upgrade on postgresql module. > Need to rename the postgresql module also for sos-2. I'm not really clear on what you're asking for here. The plug-in was already renamed to pgsql on the sos-2.x branch.
(In reply to Bryn M. Reeves from comment #10) > I'm not really clear on what you're asking for here. The plug-in was already > renamed to pgsql on the sos-2.x branch. Sorry,that was a note for log-collector. Not an issue inside sos.
*** Bug 1087073 has been marked as a duplicate of this bug. ***
I ran into this issue this afternoon. Based on the info presented in comment #7, I enabled the nightly repos and managed to get it installed from there with version 3.5.0-0.0.master.20140416.git4d6ff27.fc20
*** Bug 1091947 has been marked as a duplicate of this bug. ***
This is now affecting the installation of ovirt-engine on F19 also - sos-3.0-23.fc19.noarch.rpm was pushed into F19 stable on 11 April 2014. Thanks to jvandewege on OFTC/IRC #ovirt, I was able to get the engine installed by: yum install sos yum downgrade sos yum install ovirt-engine
Re-targeting to 3.4.2 as per comment #15. You may need also to add sos to exclude list in /etc/yum.conf adding the following line: exclude=sos
I solve installing the 3.5 version of ovirt-engine on F19 But, the 3.4 version not works anyway yum install -y http://plain.resources.ovirt.org/pub/yum-repo/ovirt-release35.rpm
This is an automated message: oVirt 3.4.2 has been released. This bug has been re-targeted from 3.4.2 to 3.4.3 since priority or severity were high or urgent.
I am running FC19. I have applied the workarounds in comments #15 and #16 However now that 3.4.2 has been released they no longer seem sufficient (or need to be backed out?). I can't upgrade my packages on my Hosted Engine due to the following: --> Processing Dependency: sos >= 3.1 for package: ovirt-log-collector-3.4.3-1.fc19.noarch --> Finished Dependency Resolution Error: Package: ovirt-log-collector-3.4.3-1.fc19.noarch (ovirt-3.4-stable) Requires: sos >= 3.1 Installed: sos-2.2-31.fc19.noarch (@fedora) sos = 2.2-31.fc19
The plugins previously shipped in the ovirt-log-collector package are now part of upstream sos. They will be included in updated sos packages for F19/20/rawhide shortly, see bug 1107126 for more details (this is the master rawhide bug - it'll be cloned shortly for F19/20). For this to work however the ovirt-log-collector package needs to be updated to remove these plugins. In your case though it looks like you have a very old version of sos installed. The sos-3.0-2.fc19 package that's current in F19 was built in June last year: http://koji.fedoraproject.org/koji/buildinfo?buildID=425714 Upstream sos is coming up to a 3.2 release shortly and we were hoping to update all of this at the same time however as the new ovirt bits are out already I'll push an update shortly bringing F19 and F20 up to sos-3.1 (that's been testing in rawhide for a few months) with the additional ovirt patches on top. I'll update this (and the related bugs) once a build is available for testing in bohdi.
The reason my sos was downgraded was due to the workarounds stated in https://bugzilla.redhat.com/show_bug.cgi?id=1037663#c15 and https://bugzilla.redhat.com/show_bug.cgi?id=1037663#c16: yum downgrade sos and: exclude=sos in /etc/yum.conf I have removed the exclude line from yum.conf, and now a yum update completes successfully. So it appears that anyone who applied the workarounds listed above should now back them out.
(In reply to Bob Doolittle from comment #22) > The reason my sos was downgraded was due to the workarounds stated in > https://bugzilla.redhat.com/show_bug.cgi?id=1037663#c15 and > https://bugzilla.redhat.com/show_bug.cgi?id=1037663#c16: > > yum downgrade sos > > and: > exclude=sos > in /etc/yum.conf > > I have removed the exclude line from yum.conf, and now a yum update > completes successfully. > > So it appears that anyone who applied the workarounds listed above should > now back them out. You should now remove exclude=sos from /etc/yum.conf and run "yum update". Everything should work now. Keeping this open because we're expecting sos-3.2 to be out in a couple of days and will need some more work.
(In reply to Bryn M. Reeves from comment #21) We ship a custom sos-3.1 within ovirt project while we wait for 3.2 :-)
> We ship a custom sos-3.1 within ovirt project while we wait for 3.2 :-) Doh - I'd forgotten about that! :) I'm happy to push out a 3.1 update to F19/20 this week with the ovirt changes if that helps the oVirt side - that's what we'd originally agreed. I was kinda hoping with the revised release date that we'd have 3.2 out by now (it's 11 days overdue..) and could just get that in right away but I don't want to hold you guys up waiting on it.
Bryn I'm fine with waiting for 3.2 if "shortly" means ~1 week.
That's my concern: we're overdue on 3.2 but we actually have quite a lot of slack in terms of when the release needs to land to make Fedora and other distro freezes. I think we're at least two weeks off unless we start dropping issues from the release (which I'd rather avoid since this is expected to be the sos release used in F21 and RHEL-7.1).
I'm backporting sos 3.1 ovirt plugin to sos 2 api for log-collector on EL6, should finish next week before 3.4.3 GA.
This is an automated message oVirt 3.4.3 has been released: * should fix your issue * should be available at your local mirror within two days. If problems still persist, please make note of it in this bug report.