On Tue, Jun 05, 2018 at 11:03:12AM +0100, Daniel P. Berrangé wrote: > On Tue, Jun 05, 2018 at 12:55:59PM +0300, Roman Kagan wrote: > > On Tue, Jun 05, 2018 at 10:24:03AM +0100, Daniel P. Berrangé wrote: > > > On Tue, Jun 05, 2018 at 12:18:59PM +0300, Roman Kagan wrote: > > > > On Tue, Jun 05, 2018 at 09:09:36AM +0100, Daniel P. Berrangé wrote: > > > > > On Mon, Jun 04, 2018 at 09:41:07PM +0300, Roman Kagan wrote: > > > > > > Not so long ago openstack-nova started to require qemu-kvm-rhev > > > > > > instead > > > > > > of qemu-kvm. > > > > > > > > > > > > This made it impossible to install on Virtuozzo, which used to work > > > > > > well > > > > > > before the change. > > > > > > > > > > > > I skimmed through the related tickets > > > > > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1367696 > > > > > > https://review.rdoproject.org/r/1900 > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1392820 > > > > > > https://review.rdoproject.org/r/9858 > > > > > > > > > > > > but failed to understand the motivation behind this change. What > > > > > > are > > > > > > those particular features that are only present in qemu-kvm-rhev and > > > > > > make the vendor-neutral requirement insufficient? So far we didn't > > > > > > notice any issues running recent enough QEMU with Nova, but I guess > > > > > > this > > > > > > must have changed. > > > > > > > > > > The qemu-kvm package in RHEL is a stable version based on QEMU 1.5.3, > > > > > and with many features disabled. > > > > > > > > > > For OSP we want to guarantee that users have the qemu-kvm-rhev package > > > > > present which is rebased on every RHEL update to most recent upstream > > > > > version and has a broader featureset installed, and is what is > > > > > actually > > > > > getting real world testing. > > > > > > > > This is exactly my problem: you're mixing up two separate things, the > > > > QEMU version (vendor-neutral) and the features that can only be found in > > > > the vendor-specific package, and I'm struggling to understand which one > > > > is the deal-breaker. > > > > > > > > E.g. if I try to install Nova from > > > > http://mirror.centos.org/centos/7/cloud/x86_64/openstack-ocata/ on my > > > > Fedora28 machine, I have no way to satisfy this qemu-kvm-rhev > > > > dependency, even though qemu-kvm installed is at version 2.11.1. > > > > > > > > Is this the intended behavior? > > > > > > In this case we don't care, because mixing distros is explicitly > > > unsupported. ie you can't expect RPMs build for CentOS7 to be able > > > to successfully dep-solve against RPMs biuld for Fedora 28. If it > > > ever worked, it is purely by luck not design. > > > > > > IIUC, RDO project explicitly dropped support for running on Fedora > > > and only targets CentOS or RHEL. > > > > I see, good to know. > > > > > > If it is, and Nova can only be used with this very special QEMU built > > > > for RHEV, what are the specific features I should be looking out for to > > > > be able to produce a compatible build? E.g. we (Virtuozzo) ship QEMU > > > > package based on approximately the same mainline QEMU version as RHEV > > > > but with different downstream patches and configuration. Is it likely > > > > not to work with Nova? > > > > > > The qemu-kvm-rhev build is not really special - in fact it is probably > > > more "normal" than the 'qemu-kvm' build because it is a modern QEMU > > > version and so has relatively few patches backported, compared to the > > > ancient 1.5.3 which has a load of patches backported. > > > > > > So if you have a QEMU build of comparable vintage to qemu-kvm-rhev > > > that would likely work. You can then solve the deps problem by adding > > > a virtual "Provides: qemu-kvm-ev = X.Y.Z" > > > > Do you mean "qemu-kvm-rhev = X.Y.Z"? We considered this, but the "rhev" > > part kinda implied vendor affiliation and a claim of compatibility which > > I wasn't sure we could guarantee. For one, our machine types differ in > > names and default properties. If this is not a problem we can go down > > this route indeed. > > AFAIK, the RDO project doesn't provide any claim of compatibility > with Virtuozzo. So I don't think having a virtual "Provides: qemu-kvm-rhev" > makes the situation worse wrt compatibility claims. > > Right now at least, Nova doesn't care about machine type names. In future > there is possibility that the Nova RPMs in RDO will care about specific > machine type names provided by qemu-kvm-rhev/qemu-kvm-ev. If that ever > happened, you would have to modify the nova.conf to override this to > work with your own QEMU builds.
Understood, thanks a lot. I think short term our best bet is to provide qemu-kvm-rhev in our QEMU package indeed. Thanks, Roman. _______________________________________________ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org