Bug 1184568

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