Bug 1018947

Sorry, bad form - there are some extra text blocks in their from the ticket I cloned.

Please ignore the sections "How reproducible:" and "Maybe some prerequisite steps are needed:"

Again, sorry for the noise in the bug report.

title should be from 3.2, right?
i assume the issue is not with the engine, but with the hosts since the issue is with a vdsm dep.

To the reporter - Could you try adding the EPEL repo on your failing host and see if can get python-inotify that way?

Yes, adding the EPEL repo on the struggling host node allowed all of the dependencies to be met and the software updated.

I asked about this in the IRC channel and someone there suggested that I file a bug.

Itamar - it was from 3.0, which came in from the oVirt/CentOS package set, to 3.3

well, ovirt 3.0 .el6 was from dreyou repo? the first ovirt version for .el6 was 3.2.1...
more than that, please note we also only test one version upgrade at a time.
so not sure what will happen post your dependency issue...

I went back to my notes -  I was using http://dev.centos.org/centos/6/ovirt/ovirt.repo as my initial Node source for ovirt packages (such as ovirt-engine-setup-3.1.0-3.26.3.el6.centos.alt.noarch.rpm), but the node software was mainly delivered by the Engine.

The Engine used two repo's EPEL and oVirt Releases:

http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm 
http://ovirt.org/releases/ovirt-release-el.noarch.rpm

It looks like the Engine couldn't resolve software dependencies for the Node it was installing to.  Hope that clarifies a little bit.

Created attachment 813106 [details]
ovirt engine 3.3 on CentOS 6.4 installed package list

Created attachment 813107 [details]
ovirt node 3.3 on CentOS 6.4 installed package list

I do not think we can do much beyond adding a release note: "not only do you need to install http://resources.ovirt.org/releases/3.3/rpm/EL/6/noarch/ovirt-release-el6-8-1.noarch.rpm, please make sure that epel-release is intalled, too"

We may even make ovirt-release explicitly require epel-release. Mike, what do you think of that?

I don't know about adding a dependency on epel-release.  Updating the instructions to indicate that we require epel is the right idea, I think.  The Download page says that Epel needs to be enabled.  We should make sure that upgrade instructions and quick start guides get updated.

In the ovirt mailing list, someone pointed out that EPEL includes some ovirt packages.  At http://mirrors.yocum.org/fedora/epel/6/x86_64/, I found

ovirt-engine-cli-3.3.0.4-1.el6.noarch.rpm
ovirt-engine-sdk-3.2.0.11-1.el6.noarch.rpm
ovirt-engine-sdk-python-3.3.0.6-1.el6.noarch.rpm
ovirt-guest-agent-1.0.8-1.el6.noarch.rpm

important, I did not get the motivation for your comment 12.

Would you verify that with ovirt-3.4 beta, the epel repository is installed and python-inotify is available to the host?

I'm sorry, I'm not able to review the ovirt-3.4 beta at the moment.  I no longer have any OVirt servers - we're using other hypervisors.

(In reply to Dan Kenigsberg from comment #14)
> important, I did not get the motivation for your comment 12.
> 
> Would you verify that with ovirt-3.4 beta, the epel repository is installed
> and python-inotify is available to the host?

Dan, with rpm unification of Fedora and CentOS in one, epel can't be installed anymore automatically.

http://gerrit.ovirt.org/#/c/23661/

It has been in review for one month before Merging it.
Now on EL6 distributions we provide a ovirt-epel repo which allows "yum install epel-release" without the need to go fetching the rpm manually.
But we can't have both unified rpm and dep on epel repo, sorry.

Why is it an issue to require epel-release from the el6 rpm of ovirt-epel?

(In reply to Dan Kenigsberg from comment #17)
> Why is it an issue to require epel-release from the el6 rpm of ovirt-epel?

because we don't have an ovirt-epel rpm, we have an ovirt-epel.repo inside ovirt-release-<version>.noarch.rpm (distribution agnostic)

In my opinion, ovirt-release.rpm should be built per distribution, just like any other rpm. I see no reason to ship ovirt-epel.repo to Fedora hosts, for example.

Anyway, for this bz this does not matter - python-inotify should be reachable by yum on el6.

(In reply to important from comment #15)
> I'm sorry, I'm not able to review the ovirt-3.4 beta at the moment.  I no
> longer have any OVirt servers - we're using other hypervisors.

Too bad, David. I hope you change your mind ;-)

(In reply to Dan Kenigsberg from comment #19)
> In my opinion, ovirt-release.rpm should be built per distribution, just like
> any other rpm. I see no reason to ship ovirt-epel.repo to Fedora hosts, for
> example.

We should really move this discussion to mailing list or to bug #1053037.

> 
> Anyway, for this bz this does not matter - python-inotify should be
> reachable by yum on el6.


Note that on el6, adding epel-release to dependencies just move the issue from python-inotify to epel-release. epel-release is not available on el6, so this is not a solution.


> 
> (In reply to important from comment #15)
> > I'm sorry, I'm not able to review the ovirt-3.4 beta at the moment.  I no
> > longer have any OVirt servers - we're using other hypervisors.
> 
> Too bad, David. I hope you change your mind ;-)

So at the moment you need to do following on hypervisor in order to get vdsm installed:

1) Install CentOS
2) add ovirt repo
cat > /etc/yum.repos.d/ovirt.repo <<END
[ovirt]
name=ovirt
baseurl=http://resources.ovirt.org/releases/3.4.0-rc2/rpm/EL/6Server/
gpgcheck=0
enabled=1
END

3) install ovirt epel via ovirt release
yumn install ovirt-release -y

4) install epel-release
yum install epel-release --nogpgcheck -y

5) yum install vdsm


-----------------------
maybe ovirt-epel.repo should contain gpgcheck=0 , so step 4 will go through without --nogpgcheck


[root@centos ~]# cat /etc/yum.repos.d/ovirt-epel.repo 
[ovirt-epel]
name=Extra Packages for Enterprise Linux 6 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch
failovermethod=priority
enabled=1
includepkgs=epel-release
--------------------------

can this be considered verified? I do not find it very convenient for the user

if step (4) is still required, then this bug is NOT verified. ovirt-release.rpm contains /etc/yum.repos.d/ovirt-epel.repo which should have been sufficient to obtaining python-inotify.

Please note that step (2) is a bit "dirty" too: /etc/yum.repos.d/ovirt.repo is included in ovirt-release.rpm. Instead, have step (3) do

  yum install http://resources.ovirt.org/releases/3.4.0-rc2/rpm/EL/6/noarch/ovirt-release-11.1.0-1.noarch.rpm

you can either decide to provide python-inotify in ovirt repo or adding it to ovirt-epel.repo at line :

includepkgs=epel-release

adding python-inotify there.

yes step 4 is still needed please check bellow

1) clean CentOS
2) yum install http://resources.ovirt.org/releases/3.4.0-rc2/rpm/EL/6/noarch/ovirt-release-11.1.0-1.noarch.rpm
3) yum install vdsm

--> Finished Dependency Resolution
Error: Package: vdsm-4.13.3-4.el6.x86_64 (ovirt-3.3-stable)
           Requires: python-inotify
Error: Package: vdsm-4.13.3-4.el6.x86_64 (ovirt-3.3-stable)
           Requires: python-argparse
Error: Package: vdsm-4.13.3-4.el6.x86_64 (ovirt-3.3-stable)
           Requires: python-pthreading
 You could try using --skip-broken to work around the problem

It is possible to list all epel packages that we depend on (not only python-inotify!), but this basically duplicates information that already exists in our .spec files.

The alternative of copying python-inotify and co. (e.g. python-daemon) from epel and distributing it within ovirt is also problematic: someone would have to keep track if we ship the current versions.

Habing ovirt-release.el6 require epel-release is still my favorite solution.

Dan, can you review the new patch?

Moving to 3.4.1 since 3.4.0 has been released

Moving the bug to ovirt-release, I'll fix it.
Patch pushed: oVirt gerrit 26330
Please review.

This is an automated message

oVirt 3.4.1 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.