Host upgrade should upgrade the whole host, not specific packages. If it will upgrade specific packages only, we will end up with an unsupported/untested configuration of the packages, which may lead to unexpected behavior of the system. As an example: very simple scenario of failing live migration due to package mis-match, which is a very common issue, when the customers upgrade selected packages only. In 3.6 we upgrade vdsm only, in 4.0.4 we upgrade selected packages (see bz#1344020 ). This is incorrect and should be fixed ASAP. This will bring to scenarios where host kernel would be kernel from RHEL 7.2 and qemu-kvm and libvirt and other packages would be from RHEL 7.3 or later. Those scenarios have never been tested by RHEV QE and it is irresponsible from our software putting the customer in an unsupported configuration. Also, based on my experience, when the customers click the upgrade button, they expect the whole host to be upgraded, same way they do with RHEV-H. They want to get all the latest updates and all the latest CVE available. Not partial update of specific packages.
As a mean term, if we cannot fix this bug right away, we should add a tooltip or information message or other type of notifications, that right now only "THIS" list of packages are going to be updated, kernel etc not included. If you are interested to upgrade the whole host, run `yum update` on the host. I would also mention that this is unsupported configuration, as we were told multiple times.
(In reply to Marina from comment #1) > As a mean term, if we cannot fix this bug right away, we should add a > tooltip or information message or other type of notifications, that right > now only "THIS" list of packages are going to be updated, kernel etc not > included. If you are interested to upgrade the whole host, run `yum update` > on the host. > I would also mention that this is unsupported configuration, as we were told > multiple times. Even now for each host, if we found some available upgrades, we send an event (and also add log message to engine.log): Host ${VdsName} has available updates: ${Packages}. This event (log) is created after each check for host upgrade (by default once a day).
(In reply to Martin Perina from comment #2) > (In reply to Marina from comment #1) > > As a mean term, if we cannot fix this bug right away, we should add a > > tooltip or information message or other type of notifications, that right > > now only "THIS" list of packages are going to be updated, kernel etc not > > included. If you are interested to upgrade the whole host, run `yum update` > > on the host. > > I would also mention that this is unsupported configuration, as we were told > > multiple times. > > Even now for each host, if we found some available upgrades, we send an > event (and also add log message to engine.log): > > Host ${VdsName} has available updates: ${Packages}. > > This event (log) is created after each check for host upgrade (by default > once a day). Martin, does it check for vdsm required packages only or all?
(In reply to Marina from comment #3) > (In reply to Martin Perina from comment #2) > > (In reply to Marina from comment #1) > > > As a mean term, if we cannot fix this bug right away, we should add a > > > tooltip or information message or other type of notifications, that right > > > now only "THIS" list of packages are going to be updated, kernel etc not > > > included. If you are interested to upgrade the whole host, run `yum update` > > > on the host. > > > I would also mention that this is unsupported configuration, as we were told > > > multiple times. > > > > Even now for each host, if we found some available upgrades, we send an > > event (and also add log message to engine.log): > > > > Host ${VdsName} has available updates: ${Packages}. > > > > This event (log) is created after each check for host upgrade (by default > > once a day). > > Martin, does it check for vdsm required packages only or all? Is checks for all packages that are defined in following config values: 1. RHEL hosts PackageNamesForCheckUpdate - cannot be changed by users, contains following packages: ioprocess mom libvirt-client libvirt-daemon-config-nwfilter libvirt-daemon-kvm libvirt-lock-sanlock libvirt-python lvm2 ovirt-imageio-common ovirt-imageio-daemon ovirt-vmconsole ovirt-vmconsole-host python-ioprocess qemu-kvm qemu-img sanlock vdsm vdsm-cli UserPackageNamesForCheckUpdate - editable using engine-config, by default empty 2. RHVH hosts OvirtNodePackageNamesForCheckUpdate - cannot be changed by users, contains following packages: ovirt-node-ng-image-update We check for upgrade of all packages listed in above configuration values.
I agree that there should be more update options as I posted to the mailinglist: http://lists.ovirt.org/pipermail/users/2017-January/079062.html - Only oVirt packages or - Yum update all packages Selectbox: - Reboot when upgrade finished This with/in the maintenance mode will save a lot of time.
(In reply to Yamakasi from comment #5) > I agree that there should be more update options as I posted to the > mailinglist: > > http://lists.ovirt.org/pipermail/users/2017-January/079062.html > > - Only oVirt packages > or > - Yum update all packages > > > Selectbox: > - Reboot when upgrade finished > > > This with/in the maintenance mode will save a lot of time. Makes sense to me. Martin - can you scope it?
Why are we no maintaining the packages that need to be updated in the host? It will make it much easier to diff between type and archs. Can we move that list to the host and only trigger according to that list?
There are no customer tickets attached, so moving upstream
(In reply to Yaniv Kaul from comment #6) > (In reply to Yamakasi from comment #5) > > I agree that there should be more update options as I posted to the > > mailinglist: > > > > http://lists.ovirt.org/pipermail/users/2017-January/079062.html > > > > - Only oVirt packages > > or > > - Yum update all packages > > > > > > Selectbox: > > - Reboot when upgrade finished > > > > > > This with/in the maintenance mode will save a lot of time. > > Makes sense to me. > Martin - can you scope it? It works for me, we will have 2 upgrade options (with user requested reboot of the host at the end): 1. Upgrade only ovirt-host package, which should upgrade all oVirt dependencies on the host (see BZ1460609) 2. Perform all available package upgrades
(In reply to Martin Perina from comment #9) > (In reply to Yaniv Kaul from comment #6) > > (In reply to Yamakasi from comment #5) > > > I agree that there should be more update options as I posted to the > > > mailinglist: > > > > > > http://lists.ovirt.org/pipermail/users/2017-January/079062.html > > > > > > - Only oVirt packages > > > or > > > - Yum update all packages > > > > > > > > > Selectbox: > > > - Reboot when upgrade finished > > > > > > > > > This with/in the maintenance mode will save a lot of time. > > > > Makes sense to me. > > Martin - can you scope it? > > It works for me, we will have 2 upgrade options (with user requested reboot > of the host at the end): > > 1. Upgrade only ovirt-host package, which should upgrade all oVirt > dependencies on the host (see BZ1460609) > 2. Perform all available package upgrades We should strive for having an homogeneous status in a cluster with regards to upgrade policy. hence it should be a cluster level configuration rather than a host one. does it makes sense?
> > > > 1. Upgrade only ovirt-host package, which should upgrade all oVirt > > dependencies on the host (see BZ1460609) > > 2. Perform all available package upgrades > > We should strive for having an homogeneous status in a cluster with regards > to upgrade policy. hence it should be a cluster level configuration rather > than a host one. does it makes sense? Today it is system-wide. I didn't see any requirement for a more fine-grained settings. I vote to either leave this as-is for now, or to upgrade everything (and not only ovirt dependencies).
(In reply to Oved Ourfali from comment #11) > > > > > > 1. Upgrade only ovirt-host package, which should upgrade all oVirt > > > dependencies on the host (see BZ1460609) > > > 2. Perform all available package upgrades > > > > We should strive for having an homogeneous status in a cluster with regards > > to upgrade policy. hence it should be a cluster level configuration rather > > than a host one. does it makes sense? > > Today it is system-wide. > I didn't see any requirement for a more fine-grained settings. > I vote to either leave this as-is for now, or to upgrade everything (and not > only ovirt dependencies). It makes sense to perform all available updates, but we also need to check if ovirt-host package is installed and if not then install it (as it's introduced for 4.2 and it will not be present on 4.0/4.1 hosts, so it won't be in the list of available updates for those hosts). So yes, it makes sense to perform only "all available" updates (with the ability to perform host restart at the end) + an expection to ovirt-host package
(In reply to Martin Perina from comment #12) > ... > (with the ability to perform host restart at the end) > ... great. as long as that is the default option
(In reply to Michal Skrivanek from comment #13) > (In reply to Martin Perina from comment #12) > > > ... > > (with the ability to perform host restart at the end) > > ... > > great. as long as that is the default option That will be a bigger change in behavior. We should let the user chose if to restart. Or give some warning around it.
that's why I say "default". Sure they can decide not to. But it should not be the default choice. Let's finally fix the misconception introduced couple releases back that leads to unpredictable behavior after an update of a system package. For people who choose to apply specific updates and know what they are doing it's fine, but very few do that.
The plan is to have 'Restart host after upgrade' checkbox in the dialog, which by default will be checked, but user can uncheck it if needed.
Manually tested on 7.4 rhel beta 1 to beta 2 candidate + system updates Tested on rhvh also
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.