If the VDSM fix is already available, then I don't see a compelling reason todo  this in libvirt - updating RPMs will already pull in the newer VDSM & cherry-picking RPM updates from 7.3 -> 7.4 is not a supported scenario. If users do that they'll quickly see the problem & be able to rectify it by fully updating.

The Vdsm fix is to be available only in RHV-4.1.z. We cannot release it to 4.0.z as that channel no longer exist, nor to 3.6.z which has seen its final release.

If someone upgrades libvirt and not vdsm (which is highly possible, as they are shipped in separate channels) while VMs are running, Vdsm would fail to restart, and his VMs would get stuck on that host, with no control path.

RHV has plenty of customers which might swam our support apparatus with annoying cases. Handling each case is easy, but the cost to Red Hat and its customers would be much higher than a one-liner addition to the downstream libvirt.spec.

I know that rebasing libvirt to 3.2 in the midlife of rhel7 has plenty of advantages to libvirt and RHV. But it has a few costs - and adding

  Conflicts: vdsm <= 4.19.16

is not the greatest of those.

(In reply to Dan Kenigsberg from comment #3)
> The Vdsm fix is to be available only in RHV-4.1.z. We cannot release it to
> 4.0.z as that channel no longer exist, nor to 3.6.z which has seen its final
> release.

This seems rather surprising/broken to me. If we are genuinely still supporting these VDSM versions, there *must* be a way for us to issue updates, otherwise we'd be unable to push out critical security patches which I can't believe.

> If someone upgrades libvirt and not vdsm (which is highly possible, as they
> are shipped in separate channels) while VMs are running, Vdsm would fail to
> restart, and his VMs would get stuck on that host, with no control path.
> 
> RHV has plenty of customers which might swam our support apparatus with
> annoying cases. Handling each case is easy, but the cost to Red Hat and its
> customers would be much higher than a one-liner addition to the downstream
> libvirt.spec.

The problem with adding such conflicts is that it leads to pretty unpleasant user experience when they try to upgrade. If the conflict triggers, because new VDSM is not available, then yum will obviously be unable to install libvirt from 7.4.  It will thus have to hold back the libvirt from 7.3, this in turn will cause a ripple effect preventing upgrade of many other RPMs. The end result is that yum either holds back loads of packages, or worse gives up throwing out largely unintelligible error messages about resolvable dependencies.

This request looks related to bug 1445531. Both are really caused by the use of layered product above RHEL. Since they have different schedules, RHEL updates may become available before a new release of the layered product (which was actually tested to work with the new RHEL) is released. And the goal is to prevent updating RHEL without also updating the layered product.

We should solve this fundamental issue in a different way than adding more and more conflicts into libvirt. IMHO either we need to issue a fix (z-stream) for the existing release of the layered product before new RHEL is shipped or we should somehow disable updating RHEL (not just libvirt) until a new layered product is available.

I'm not completely against the conflicts for 7.4 as we don't have a lot of time to deal with this, but I'd really like to see a better solution for the future.

(In reply to Daniel Berrange from comment #4)
> The problem with adding such conflicts is that it leads to pretty unpleasant
> user experience when they try to upgrade. If the conflict triggers, because
> new VDSM is not available, then yum will obviously be unable to install
> libvirt from 7.4.  It will thus have to hold back the libvirt from 7.3, this
> in turn will cause a ripple effect preventing upgrade of many other RPMs.
> The end result is that yum either holds back loads of packages, or worse
> gives up throwing out largely unintelligible error messages about resolvable
> dependencies.

It's worse, but in the perspective of RHV users, being unable to upgrade libvirt and its dependencies until a fresh vdsm is available on a host is still much better than loosing the hypervisor and its currently-running VMs until that vdsm is available.

Both scenarios provide an awful experience for users - just awful in different ways. To get a good experience for users we should issue an update for effect VDSM versions that we expect to continue supporting on 7.4, so users don't hit the problem in the first place.

(In reply to Dan Kenigsberg from comment #3)
> The Vdsm fix is to be available only in RHV-4.1.z. We cannot release it to
> 4.0.z as that channel no longer exist, nor to 3.6.z which has seen its final
> release.

it is the same -4- channel, so once 4.1.z/async goes live it's automatically available to all 4.0 installations

In other words the Conflicts hack is no longer required, is it?