Description of problem: When updating from Satellite 6.0.6 to 6.0.7, there are manual steps that must be completed to finish the installation (as described in https://access.redhat.com/errata/RHBA-2015:0054). If the user runs 'yum update' without completing these steps, the system is left somewhat unusable. (see https://access.redhat.com/solutions/1325953) This RFE requests a separate process/function similar to what other applications do, which is: * Lock the application's packages at a specific version (using the yum version-lock plugin for example) * Provide a script that completes the various (formerly manual) upgrade steps, so that we can ensure they are done in the correct order. And also give the user the option to backup the DB and other sundry items to make sure the process happens in the correct order. Because users don't always read the docs prior to issuing 'yum update', and we should do whatever possible to not leave them with a broken system. Version-Release number of selected component (if applicable): foreman-1.6.0.51-1
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
+1 customers quite often don't read every errata text just assuming the steps are the same
I'd like to add that some message in the web ui would be nice (like the schema upgrade in Satellite 5)
+1 this should be automatic or some sort of notification to the user be provided. Most users will just yum update and then sit and troubleshoot the issue for some time.
I'm reopening this, there is work to be done. One proposal from Rich Jerrido is to use version locking mechanism to control the Satellite updates. Users would need to perform some extra step, perhaps `katello-installer --upgrade` unlocks the version locks, runs yum update, and locks again. Prevents a lot of pain when the errata is not read for instructions.
Per 6.3 planning, moving out non acked bugs to the backlog
*** Bug 1381376 has been marked as a duplicate of this bug. ***
If I understand the version locking concept properly, we would be able to lock the current version of satellite related rpms (all except installer packages). This would make running the yum update more safe and the installer would drive the upgrade process in more controlled way and it would unblock additional improvements in the upgrade process, such as: * https://bugzilla.redhat.com/show_bug.cgi?id=1382506 - info about the next version * https://bugzilla.redhat.com/show_bug.cgi?id=1382510 - info about steps to be performed * https://bugzilla.redhat.com/show_bug.cgi?id=1382515 - pre-upgrade part of the upgrade process * https://bugzilla.redhat.com/show_bug.cgi?id=1314742 - maintenance mode Is this what this BZ suggest, or did I got it wrong?
That is *exactly* what is being requested. As a user, I expect yum update to be a safe command to run arbitrarily. If this BZ is implemented as I an envisioning, the user would - install satellite as per the documentation. - as part of the installation, we version lock all the packages satellite needs (so foreman*, katello*, httpd, etc). - The upgrade documentation then becomes: - yum update satellite-installer - satellite-installer --upgrade. As part of the pre-upgrade portion, - we'd lift the versionlock, - update the satellite-specific packages, - perform any upgrade tasks. - then create a new versionlock (with the new packages NVREA) And repeat per update.
Created redmine issue http://projects.theforeman.org/issues/17190 from this bug
*** Bug 1404203 has been marked as a duplicate of this bug. ***
+1 just "upgraded" a 6.2.6 and although the logs and the CLI output said "upgrade successful" it was still at 6.2.6. Needed to # yum update -y && satellite-installer --scenario satellite --upgrade for it to be successful. Needs to be more clear. Perhaps fail if detects certain "upgrade" packages to be the same level as what is currently installed?
I am breaking out the yum repo lock porition from this into https://bugzilla.redhat.com/show_bug.cgi?id=1512600 I have also linked to that bug two others ( https://bugzilla.redhat.com/show_bug.cgi?id=1459358, https://bugzilla.redhat.com/show_bug.cgi?id=1316246) which we may or may not implement as a group. This but should be verified only for the existence of foreman-maintain. I expect there to be future RFE's for foreman-maintain to increase the robustness of the tooling
This bz includes many cases & RFEs around overall upgrade process. I believe all of them can't be deal in same issue. Just to summarize all issues and their corresponding bugs to know what has already been done and what's left and where to track left out. As per original bz description: ================================= A) yum version lock - should be handled with https://bugzilla.redhat.com/show_bug.cgi?id=1512600 B) Script to perform various upgrade steps in general - Done and Handled with foremain-maintain tooling. Various other enhancements are listed in comment13 As per comment14. First request is handled with B) and 2nd with A) C) Comment4 and comment5 should be handled with bug: https://bugzilla.redhat.com/show_bug.cgi?id=1459358 (from comment25) In short, as per Bryan comment25, since we have filed separate issues for each request, so this bug can be verified with existence of foreman-maintain. Please feel free to comment if anyone has any concern on this comment.
Verified with foreman_maintain package rubygem-foreman_maintain-0.1.1-1.el7sat.noarch.rpm Tooling exists and performs health checks as below and upgrade as well. Tooling has advanced options too ~]# foreman-maintain health check Running preparation steps required to run the next scenarios ================================================================================ Setup hammer: Using defaults from /root/.hammer/cli.modules.d/foreman.yml New settings saved into /etc/foreman-maintain/foreman-maintain-hammer.yml [OK] -------------------------------------------------------------------------------- Running ForemanMaintain::Scenario::FilteredScenario ================================================================================ Check for paused tasks: [OK] -------------------------------------------------------------------------------- Check whether all services are running using hammer ping: [OK] -------------------------------------------------------------------------------- # foreman-maintain advanced procedure run --help Usage: foreman-maintain advanced procedure run [OPTIONS] SUBCOMMAND [ARG] ... Parameters: SUBCOMMAND subcommand [ARG] ... subcommand arguments Subcommands: foreman-tasks-delete Delete tasks foreman-tasks-fetch-tasks-status Fetch tasks status and wait till they finish foreman-tasks-resume Resume paused tasks foreman-tasks-ui-investigate Investigate the tasks via UI hammer-setup Setup hammer installer-upgrade Procedures::Installer::Upgrade katello-service-restart katello-service restart katello-service-start katello-service start katello-service-stop katello-service stop maintenance-mode-disable Turn off maintenance mode maintenance-mode-enable Turn on maintenance mode packages-install Procedures::Packages::Install packages-update Procedures::Packages::Update repositories-setup Setup repositories sync-plans-disable disable active sync plans sync-plans-enable re-enable sync plans
~]# foreman-maintain upgrade list-versions 6.3.z [root@dell-per720xd-01 ~]# foreman-maintain upgrade check --target-version not specified Possible target versions are: 6.3.z
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. > > > > For information on the advisory, and where to find the updated files, follow the link below. > > > > If the solution does not work for you, open a new bug report. > > > > https://access.redhat.com/errata/RHSA-2018:0336