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:
(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.
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
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.
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