Description of problem: I'm using two host: one for the engine, the other as an hypervisor. Both with latest fedora 19 updates. I installed the ovirt engine, release 3.5 RC2, on the first host and from the web admin UI I was trying to add the second host. I forgot to add oVirt 3.5 repo on it and host-deploy doesn't check it at all; it simply gets older packages from fedora repository generating than a nonworking setup. Than to correct it I added oVirt 3.5 RC2 repo on the second host trying to add it again. host-deploy updates vdsm stuff from the newer repo but it skips libvirt stuff. Resulting setup doesn't work Version-Release number of selected component (if applicable): 3.5 RC2 How reproducible: 100% Steps to Reproduce: 1. two fedora 19 hosts, install the engine on one of them 2. without adding any additional rpms repository on the second host try to add it via the web admin gui 3. it fails, so let's add the required yum repository to the second host 4. try again to add it via the webadmin GUI Actual results: host-deploy upgrade vdsm stuff but ignores libvirt-client, libvirt-daemon, libvirt-daemon-config-nwfilter, libvirt-daemon-driver-interface, libvirt-daemon-driver-network, libvirt-daemon-driver-nodedev, libvirt-daemon-driver-nwfilter, libvirt-daemon-driver-qemu, libvirt-daemon-driver-secret, libvirt-daemon-driver-storage, libvirt-daemon-kvm, libvirt-daemon-qemu, libvirt-lock-sanlock, libvirt-python, sos and so the system is not able to add the host. Manually upgrading that packages and trying again it completes successfully Expected results: The behavior is not coherent, two alternatives: 1. upgrade all the required packages 2. upgrade nothing advising the user that he has to manually upgrade Additional info:
I mark it as dup of bug#1142953 as this report mixes two different issues. the issue of bug#1142953 and issue of vdsm dependencies. if you think there is an issue of vdsm dependencies not pulling required libvirt version, please open a separate bug specifying vdsm and what libvirt version is required and what is pulled within vdsm spec. host-deploy updates only required top level packages, it is the responsibility of the packages to pull right dependencies. *** This bug has been marked as a duplicate of bug 1142953 ***
(In reply to Alon Bar-Lev from comment #1) > host-deploy updates only required top level packages, it is the > responsibility of the packages to pull right dependencies. I understood your point but I'm not sure that it's that easy or that robust. We are facing different cases between fresh setups and updates: * case 1: I add oVirt 3.5 RC2 repo on fresh fedora19 setup and than I try to add as an host via the webadmin GUI. Host-deploy chooses the most recent version of vdsm-* and libvirt-* cause neither of them is installed and everything works as expected. * case 2: for any possible reasons (including human mistakes) I already added on my host some virtualization related rpms. Host-deploy (due to dependencies) now updates only vdsm-* but it ignores libvirt-*. So you'll end having a system qith a fresh vdsm but with an older libvirt. Theoretically it should work assuming that you accept to downgrade the cluster compatibility level to 3.3 (in practice we have some problems also on that side, see [1]). But I assume that we are upgrading vdsm stuff just to gain 3.5 compatibility level so, on that side, no reasons to skip libvirt stuff if we really need to get 3.5 compatibility level. Of course we can get that result also enforcing a stricter dependency schema between vdsm and libvirt but theoretically vdsm, assuming that you accept to downgrade the cluster compatibility level, should be also compatible with previous libvirt stuff so on my opinion it's a strict dependency. On debian based system, for instance, there are also recommended and suggested dependency levels; on yum instead we have just one type of dependency. So if vdsm is able to work with previous version of libvirt it's not strictly dependent from latest libvirt release. But if we want/need to upgrade vdsm to gain latest cluster compatibility level we have to do the same with libvirt. So, on my opinion, it's better to upgrade from host-deploy both vdsm and libvirt at the same time or neither one of them. Than we have a similar issue with sos which is needed for log-collector but this is a second order problem. Just to add some details, if I add oVirt 3.5 RC2 repo on fedora 19 system, host-deploy upgrades these: ioprocess.x86_64 0:0.12.0-2.fc19 numactl.x86_64 0:2.0.8-4.fc19 python-ioprocess.noarch 0:0.12.0-2.fc19 vdsm-cli.noarch 0:4.16.4-0.fc19 vdsm-jsonrpc.noarch 0:4.16.4-0.fc19 vdsm-python-zombiereaper.noarch 0:4.16.4-0.fc19 vdsm-python.noarch 0:4.16.4-0.fc19 vdsm-python.x86_64 0:4.14.8.1-0.fc19 vdsm-xmlrpc.noarch 0:4.16.4-0.fc19 vdsm-yajsonrpc.noarch 0:4.16.4-0.fc19 vdsm.x86_64 0:4.16.4-0.fc19 To get a complete setup achieving 3.5 cluster compatibility level user has to manually upgrade to: kexec-tools-2.0.4-27.fc19.x86_64 libvirt-client-1.1.3.2-1.fc19.x86_64 libvirt-daemon-1.1.3.2-1.fc19.x86_64 libvirt-daemon-config-nwfilter-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-interface-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-network-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-nodedev-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-nwfilter-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-qemu-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-secret-1.1.3.2-1.fc19.x86_64 libvirt-daemon-driver-storage-1.1.3.2-1.fc19.x86_64 libvirt-daemon-kvm-1.1.3.2-1.fc19.x86_64 libvirt-daemon-qemu-1.1.3.2-1.fc19.x86_64 libvirt-lock-sanlock-1.1.3.2-1.fc19.x86_64 libvirt-python-1.1.3.2-1.fc19.x86_64 sos-3.1-1.1.fc19.ovirt.noarch No problems instead of system without libvirt cause host-deploy simply chooses most recent version as vdsm dependencies. I'm reopening it while we find what's to be fixed and how. [1] - https://bugzilla.redhat.com/1142941
I asked to open a new bug regarding the vdsm->libvirt specific issues. this should not assigned to host-deploy. once again, a standard yum transaction is applied, vdsm is updated while it should pull whatever dependencies requires, if something fails the entire transaction should be rolledback, this is all yum behavior. ovirt-host-deploy should not care what dependencies vdsm is using in this regard. Please do not re-open this one. *** This bug has been marked as a duplicate of bug 1142953 ***
Sorry Alon, I agree about yum transaction. Moving to vdsm since it's a real dependency issue. Setting priority to medium since workaround exist as per comment #2 and not blocking 3.5.0 on this. Up to VDSM guys either to fix the dependencies or decide to address single bugs users will open when hitting this issue.
(In reply to Sandro Bonazzola from comment #4) > Sorry Alon, I agree about yum transaction. Moving to vdsm since it's a real > dependency issue. Setting priority to medium since workaround exist as per > comment #2 and not blocking 3.5.0 on this. > > Up to VDSM guys either to fix the dependencies or decide to address single > bugs users will open when hitting this issue. guys, these long confusing bugs are not helping anyone. if comment#0 of bug opened by engineer is not describing the real issue and is mix of two issues and non clear root cause, then it should be closed an a fresh bug should be opened. this is how you work with bugs. you can continue discussing whatever you like in fresh new bug and make it easier to everyone.
I don't mind keeping this bug, or opening a fresh new one. The important thing is to explain what is a "nonworking setup". Which libvirt version is installed? Which one do you think are required for proper functioning? What's not working? Would doing `yum upgrade -y` prior to ovirt-host-deploy solve your pains?
(In reply to Dan Kenigsberg from comment #6) > I don't mind keeping this bug, or opening a fresh new one. The important > thing is to explain what is a "nonworking setup". > > Which libvirt version is installed? Initial situation: libvirt-daemon.x86_64 1.0.5.9-1.fc19 from @updates and vdsm.x86_64 4.14.8.1-0.fc19 from @updates I add our oVirt 3.5 RC2 repo and than I try to add the host. host-deploy updates vdsm, no action on libvirt We get: libvirt-daemon.x86_64 1.0.5.9-1.fc19 from @updates and vdsm.x86_64 4.16.4-0.fc19 from @ovirt-3.5-pre With this configuration it fails adding the host. As far as I know, with this configuration, I have to downgrade the cluster compatibility level to 3.3 to have some chances. It fails also trying to add to a 3.3 cluster. > Which one do you think are required for > proper functioning? With libvirt-daemon.x86_64 1.1.3.2-1.fc19 from @ovirt-3.5-fedora-virt-preview and vdsm.x86_64 4.16.4-0.fc19 from @ovirt-3.5-pre it works as expected and I can successfully add that host to a 3.5 cluster. > What's not working? host-deploy fails adding the host to a cluster; the host is not usable. > Would doing `yum upgrade -y` prior to ovirt-host-deploy solve your pains? Yes, it does.
I assume this bug should either be CLOSE NOTABUG or a duplicate of Bug 1142941 ?
I think so, Barak. Simone, if not - please explain why. According to Fedora rules, Vdsm's F19 build cannot depend on a libvirt version that is out of Fedora. Since F19 is nearing its end-of-life, I am not willing to build its Vdsm elsewhere. ovirt-host-deploy could agree to have a brutal `yum upgrade` phase; some users would find it useful; some would curse its brutality. Anyway, without such a phase, we cannot handle this issue. *** This bug has been marked as a duplicate of bug 1142941 ***