Bug 585012 - Suggestions to prevent satellite upgrade issues, and documentation clarifications
Suggestions to prevent satellite upgrade issues, and documentation clarificat...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Upgrades (Show other bugs)
530
All Linux
medium Severity medium
: ---
: ---
Assigned To: Milan Zázrivec
Michael Mráka
:
Depends On:
Blocks: sat540-blockers sat540-upgrades
  Show dependency treegraph
 
Reported: 2010-04-22 18:09 EDT by Xixi
Modified: 2010-10-28 10:51 EDT (History)
5 users (show)

See Also:
Fixed In Version: rhn-upgrade-5.4.0.5-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-28 10:51:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Xixi 2010-04-22 18:09:47 EDT
Description of problem:
Customer's Satellite upgrade was delayed because of some confusion regarding the upgrade steps. Satellite server was down during this time. Customer suggests the following w/r/t Satellite upgrade & documentation:

"1. Have the upgrade process QA'ed by people unfamiliar with Satellite troubleshooting and support. Provide them with nothing but what customers get.  

2. I'm pretty sure the instructions omit the simple fact that the install.pl script used in scenario-1b Step 1 is located in the root directory of the 5.3 ISO. Which also implies that there should at least be some mention that the ISO needs to be mounted by this point.

3. If you have a bash one-liner to check whether the embedded DB is 64-bit and a subsequent instruction to execute a sql script if that's the case, why isn't this part of either the install.pl or the schema upgrade command? Why are humans being used as an if-block?

4. If a human being can parse the output of `db-control report` and a SQL-5-liner to determine whether there is sufficient tablespace to complete the upgrade, can't a couple of extra lines in install.pl do it too? And add any necessary extents too?

5. If it were made clear in Step 1 of scenario-1b that install.pl could be re-invoked safely in the event of a problem, the [upgrade issue support] ticket may not have been necessary."

Version-Release number of selected component (if applicable):
Red Hat Network (RHN) Satellite 5.3.0

How reproducible:
Always.

Steps to Reproduce:
1. See above.

Actual results:
See above.

Expected results:
See above.

Additional info:
Comment 1 Milan Zázrivec 2010-08-26 12:09:35 EDT
(In reply to comment #0)
> "1. Have the upgrade process QA'ed by people unfamiliar with Satellite
> troubleshooting and support. Provide them with nothing but what customers
> get.  

The upgrades are being tested by the Satellite QA team.

> 2. I'm pretty sure the instructions omit the simple fact that the install.pl
> script used in scenario-1b Step 1 is located in the root directory of the 5.3
> ISO. Which also implies that there should at least be some mention that
> the ISO needs to be mounted by this point.

I made this part more clear in upgrade instructions.

> 3. If you have a bash one-liner to check whether the embedded DB is 64-bit and
> a subsequent instruction to execute a sql script if that's the case, why isn't
> this part of either the install.pl or the schema upgrade command? Why are
> humans being used as an if-block?

I've created satellite-oracle-64bit-fix.sh which will do just this.
Instructions updated.

> 4. If a human being can parse the output of `db-control report` and a
> SQL-5-liner to determine whether there is sufficient tablespace to
> complete the upgrade, can't a couple of extra lines in install.pl
> do it too? And add any necessary extents too?

This is an operation which will eat part of disk space of the satellite
system being upgraded and as such requires consideration of a person
who was granted administration rights to the system.

I don't think extending the tablespaces automatically (inside install.pl)
is a good idea.

> 5. If it were made clear in Step 1 of scenario-1b that install.pl could be
> re-invoked safely in the event of a problem, the [upgrade issue support] 
> ticket may not have been necessary."

I'm going to disagree with the statement telling "install.pl could be
re-invoked safely in the event of a problem".

I can think of many situations in which re-running install.pl won't
resolve anything.

Unless this point is made more clear, I'm afraid I'm going to say no
to this.
Comment 3 Milan Zázrivec 2010-08-27 09:36:28 EDT
Matter of fact(In reply to comment #1)
> > 3. If you have a bash one-liner to check whether the embedded DB is 64-bit and
> > a subsequent instruction to execute a sql script if that's the case, why isn't
> > this part of either the install.pl or the schema upgrade command? Why are
> > humans being used as an if-block?
> 
> I've created satellite-oracle-64bit-fix.sh which will do just this.
> Instructions updated.

Matter of fact, this step is no longer needed for Sate 5.4 upgrades
and is being done automatically during standard oracle-server
upgrade.

satellite.git: d7af969ae3bae71f86bb3d9607920c47abfb874e
Comment 4 Michael Mráka 2010-10-05 09:07:43 EDT
Verified. rhn-upgrade-5.4.0.6-1

2. all scenarios notice it necessary to have installation ISo mounted,
3. direct uses of sqlplus have been converted to simple scripts.
Comment 6 Clifford Perry 2010-10-28 10:47:00 EDT
The 5.4.0 RHN Satellite and RHN Proxy release has occurred. This issue has been resolved with this release. 


RHEA-2010:0801 - RHN Satellite Server 5.4.0 Upgrade
https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10332

RHEA-2010:0803 - RHN Tools enhancement update
https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10333

RHEA-2010:0802 - RHN Proxy Server 5.4.0 bug fix update
https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10334

RHEA-2010:0800 - RHN Satellite Server 5.4.0
https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10335

Docs are available:

http://docs.redhat.com/docs/en-US/Red_Hat_Network_Satellite/index.html 

Regards,
Clifford

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