If someone has RHV-3.6 hypervisor, we would like him to stay on RHEL-7.3. Therefore, next 3.6.z should have a vdsm tool configurator calling subscription-manager --set=7.3 (once per host)
A serious flaw in this idea is the upgrade path. Once the release is --set to 7.3, one cannot upgrade to RHV-4's Vdsm because it hard-requires el-7.4's libvirt and co. We can require customers to vdsm-tool unconfigure --module subscription_manager before trying to `yum update vdsm`. Does this make sense?
(In reply to Dan Kenigsberg from comment #7) > A serious flaw in this idea is the upgrade path. Once the release is --set > to 7.3, one cannot upgrade to RHV-4's Vdsm because it hard-requires el-7.4's > libvirt and co. > > We can require customers to > vdsm-tool unconfigure --module subscription_manager > > before trying to `yum update vdsm`. Does this make sense? That won't work, it doesn't scale. Didn't we say that we will put the 'subscription-manager --set=7.4' in the RPM upgrade pre script?
or do: vdsm-tool unconfigure --module subscription_manager
(In reply to Yaniv Lavi from comment #8) > Didn't we say that we will put the 'subscription-manager --set=7.4' in the > RPM upgrade pre script? That's too late. If the requirements of vdsm.rpm are not satisfied, its pre script would not be run. `unconfigure` should be run before attempting `yum upgrade vdsm`; it can be added to the host upgrade command.
After discussion with Didi I have filed bug 1509650 to track the suggestion of comment 10 in ovirt-host-deploy.
After discussion with Jiri Belka, it is unclear how the suggested code is to be automatically deployed to hosts.