Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1367674 - Review upgrade procedures
Summary: Review upgrade procedures
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Docs Install Guide
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: Unspecified
Assignee: Stephen Wadeley
QA Contact: Brandi Munilla
URL:
Whiteboard:
Depends On: 1362527 1363814 1364900 1366391 1373273
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-17 08:26 UTC by Stephen Wadeley
Modified: 2019-09-25 20:37 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-19 09:46:24 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1363814 0 high CLOSED self registered satellite upgrade guide needs more steps, and not to turn off katello-services 2021-12-10 14:42:50 UTC

Internal Links: 1363814

Description Stephen Wadeley 2016-08-17 08:26:56 UTC 
Description of problem:

Many changes have been made to upgrade procedures post 6.2 GA. They should be reviewed for inconsistencies and command output examples verified or added where required.

Version-Release number of selected component (if applicable):

n_2468191_installation-guide_version_6.2_edition_1.0_release_0-revision_8676221

Document URL: 


6.1.1. Upgrading Satellite Server
https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/installation-guide/chapter-6-upgrading-satellite-server-and-capsule-server#upgrading_satellite_server

6.2.2. Upgrading To Disconnected Satellite Server version 6.2
https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/installation-guide/chapter-6-upgrading-satellite-server-and-capsule-server#upgrading_to_disconnected_satellite_server_version_6_2

6.3. Upgrading Capsule Servers
https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/installation-guide/chapter-6-upgrading-satellite-server-and-capsule-server#upgrading_capsule_server


6.6. Upgrading a Self-Registered Satellite Server
https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/installation-guide/chapter-6-upgrading-satellite-server-and-capsule-server#upgrading_self_registered_satellite
Comment 1 Stephen Wadeley 2016-09-09 07:25:54 UTC 
While fixing the Self-Registered Satellite procedure[1], I improved the section that asks you to check your 6.1 system is really up to date.

Look for the step "If you have new packages after updating"


[1] Upgrading a Self-Registered Satellite Server - https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/installation-guide/chapter-6-upgrading-satellite-server-and-capsule-server#upgrading_self_registered_satellite
Comment 2 Stephen Wadeley 2016-09-13 11:13:44 UTC 
Customer Portal user reports:


FYI, Apparently you MUST stop virt-who PRIOR to running the upgrade. Otherwise the data it adds may be corrupted. We ended up having to purge all of our VMware hosts and re-add.
Comment 4 Stephen Wadeley 2016-09-14 09:04:20 UTC 
(In reply to Stephen Wadeley from comment #2)
> Customer Portal user reports:
> 
> 
> FYI, Apparently you MUST stop virt-who PRIOR to running the upgrade.
> Otherwise the data it adds may be corrupted. We ended up having to purge all
> of our VMware hosts and re-add.

I have been told:
As  virt-who is similar to any other client and they work by issuing HTTP POSTs/PUTs to various API endpoints, so it seems not possible that they could cause mischief during the upgrade if httpd is stopped.
Comment 5 Andrew Dahms 2016-09-20 12:28:13 UTC 
Assigning to Stephen for review.
Comment 6 Stephen Wadeley 2016-09-20 12:38:47 UTC 
In:
6.1.1. Upgrading Satellite Server

Step 13: In the web UI, go to Hosts > Discovered hosts. If there are discovered hosts
Just after enabling the new 6.2 repos


In:
6.2.2. Upgrading To Disconnected Satellite Server version 6.2

Step 5: In the web UI, go to Hosts > Discovered hosts. If there are discovered hosts
this is just before stopping the katello-service. It has to be there because you need the service to be running to do this command.

In:
6.3. Upgrading Capsule Servers
Step 10: In the web UI, go to Hosts > Discovered hosts. If there are discovered hosts


In:
6.6. Upgrading a Self-Registered Satellite Server

Step 17: In the web UI, go to Hosts > Discovered hosts. If there are discovered hosts
Just after enabling the new 6.2 repos

CONCLUSION: We could move this step in all other procedures to be the same as the disconnected procedure, but not the other way around. I think this is low priority.
Comment 7 Stephen Wadeley 2016-09-20 12:39:36 UTC 
In
6.1.1. Upgrading Satellite Server

Step 20 , with substeps
substep c:
this sentence "Because the above "no operation" command does not actually create the files, and some Puppet resources in the module expect them to be there, some failure messages are to be expected." is at the end of the explanation of the --noop command and should be added to other procedures.

In:
6.2.2. Upgrading To Disconnected Satellite Server version 6.2
Step 9

no such sentence and no substeps

In:
6.3. Upgrading Capsule Servers
no such sentence and no substeps



In:
6.6. Upgrading a Self-Registered Satellite Server
Step 26

no such sentence and no substeps
Comment 8 Stephen Wadeley 2016-09-20 12:40:12 UTC 
In:
6.1.1. Upgrading Satellite Server
Steps 8 and 9 do not take into account that you might need to start the service if neither step was required.

this issue does not arise in "6.2.2. Upgrading To Disconnected Satellite Server version 6.2" because it links to 
"Downloading and Installing from a Disconnected Network"


In:
6.3. Upgrading Capsule Servers
Steps 6 and 7 do not take into account that you might need to start the service if neither step was required.

Step 8: Disable the repositories for the previous version of Satellite.
Style violation

6.6. Upgrading a Self-Registered Satellite Server
Step 11 has substeps to handle this issue and should be used in other procedures
Comment 9 Stephen Wadeley 2016-09-20 12:40:25 UTC 
In
6.6. Upgrading a Self-Registered Satellite Server

In between disabling old repos and enabling the new repos, it has a detailed step:

Step 14 "Change the repositories in the web UI from 6.1 to 6.2."

this step could be used in other procedures. Except we do not need to mention the tools repo on non-self registered Satellite.

For "6.1.1. Upgrading Satellite Server"
see steps 10 to 12

This is not mentioned in "6.2.2. Upgrading To Disconnected Satellite Server version 6.2"
this needs testing, I think there should still be repos in web UI 


Not mentioned in 6.3. Upgrading Capsule Servers, because you do not configure this on a Capsule, they have no web UI.
Comment 13 Stephen Wadeley 2016-09-29 08:09:54 UTC 
Hello Mike

A subscriber found that restarting the database daemon in use, mongod or postgresql, made the `--noop` test run complete successfully. Do you think is is safe to do that? 

Is it safe and a good idea for me to add that to the upgrade procedure?

The idea of adding the `--noop` dry run mainly for the benefit of those with custom Apache configs. I have re-written that `--noop` step to be a series of substeps to make it easier to skip for those that do not want or need to do it. That change is not yet live except for the self-reg Sat procedure.




[1]
https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/installation-guide/chapter-6-upgrading-satellite-server-and-capsule-server#comment-1103351
Comment 28 Brad Buckingham 2016-10-12 19:18:46 UTC 
Responding to some questions on comment 13, comment 25, comment 26 and comment 27.

Re: Comment 13:
- If restarting the databases enables the --noop to run successfully, I see no reason not to include it.  Since we do tell the user to execute 'katello-service stop' prior to reaching the optional --noop step, we may want to tell them to run it again at the end of that step to place the server back in the same initial state that they would be in, had they skipped --noop.

Re: Comment 25:
- It is correct that we do not currently have an 'upgrade_check' for the Capsule.  At this time, the checks that it performs are only applicable to the Satellite server.  In the future, it is quite possible that we may have the same or something similar for the Capsule.

Re: Comment 26:
- Including the suggested text for the Capsule is reasonable.  Similar to the Satellite, the Capsule could be either physical or virtual.

Re: Comment 27:
- Steps 8 & 9 are still applicable.  They are being used to ensure that the Satellite server is upgraded to the latest 6.1.z (e.g. 6.1.10) before they attempt to upgrade to 6.2 (e.g. steps 14+).
Comment 29 Stephen Wadeley 2016-10-13 10:08:18 UTC 
Thank you very much Brad for comment 28
Comment 30 Stephen Wadeley 2016-10-13 10:20:24 UTC 
Hello Brad

Re comment 13

Under what circumstances would you be using Mongodb or PostgreSQL as the database? The subscribers comment I linked to implied it was one or the other, not both.

The Installation Guide only mentions postgresql in the appendix[1] under "Increasing the Shared Buffer and Work Memory" without any explanation of context, i.e. assuming everyone on RHEL7 is using PostgreSQL. Is that an omission, does the guide need to have more detail?



Thank you


[1] https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/installation-guide/appendix-a-large-deployment-considerations
Comment 32 Brad Buckingham 2016-10-13 15:56:05 UTC 
Re: comment 30

Satellite 6.2 currently uses both mongo and postgres.

On the satellite server, it will use postgres store data required for foreman (and associated plugins) and candlepin.  Mongo is used to store data required for pulp.

On the capsule server, it uses mongo to store data require for pulp.
Comment 43 Stephen Wadeley 2016-10-19 09:46:24 UTC 
Hello

These changes are now live on the customer portal.

Thank you
Note You need to log in before you can comment on or make changes to this bug.