SDP-512

Adam Morriss
Closed
upgrade.sh needs clearer documented explanation

The documentation needs to be clear that the system admin must not attempt to build any of the symlinks or rename the p4/p4d binaries themselves, as this is handled by the upgrade script.

The current documentation explains what is done, but does not make it clear what must not be done. To allow the admin to carry out these tasks themselves, the documentation must remove any ambiguity and prevent the need to ask questions, or avoid the situation where an admin attempts to be helpful and implements some part of the process themselves.

Currently, the docs state this:

4.1 Server upgrades
Upgrading a server instance in the SDP framework is a simple process involving a few steps.
* Download the new p4 and p4d executables for your OS from ftp.perforce.com and place them in
/p4/common/bin
* Run:
/p4/common/bin/upgrade.sh instance
* If you are running replicas, upgrade the replicas first, and then the master (outside -> in)

-- and --

5.2.1 upgrade.sh
Runs a typical upgrade process, once new p4 and p4d binaries are available in /p4/common/bin.
This script will:
* Rotate the journal (for clean recovery point)
* Apply all necessary journals to offline_db
* Stop the server
* Create an appropriately versioned link for new p4/p4d/p4broker etc
* Link those into /p4/1/bin (per instance)
* Run p4d -xu on live and offline_db to perform database upgrades
* Restart server
Location: /p4/common/bin
Status
Closed
Project
perforce-software-sdp
Severity
A
Reported By
amo
Reported Date
Modified By
robert_cowham
Modified Date
Owned By
amo
Component
doc
Type
Bug