SDP-666
Suspended
There doesn't appear to be a way to do an upgrade via upgrade.sh WITHOUT having a local offline_db setup.
It is possible to skip phase 1 (with -M) but there are steps in phases 4 and 5 that reference the offline_db paths and will bail with "Journal rotation failed during offline_db upgrade phase". This means the upgrade won't complete / be considered a success and move on to later steps (i.e. starting the broker) even though p4d is up.
It would be great to have a way to skip all the offline_db checks/work, similar to how we can set DoOfflineDBTest=0 in verify_sdp.sh.
It is possible to skip phase 1 (with -M) but there are steps in phases 4 and 5 that reference the offline_db paths and will bail with "Journal rotation failed during offline_db upgrade phase". This means the upgrade won't complete / be considered a success and move on to later steps (i.e. starting the broker) even though p4d is up.
It would be great to have a way to skip all the offline_db checks/work, similar to how we can set DoOfflineDBTest=0 in verify_sdp.sh.
- Status
- Suspended
- Project
- perforce-software-sdp
- Severity
- C
- Reported By
- Domenic
- Reported Date
- 4 years ago
- Modified By
- C. Thomas Tyler
- Modified Date
- 4 years ago
- Owned By
- Domenic
- Dev Notes
- 2021-08-22 ttyler: Suspended per comments.
- Component
- core-unix
- Type
- Feature
There presently isn't a way to upgrade without a valid offline_db, by design.
I'm a bit concerned about allowing upgrades on a master to proceed without an offline_db, since that could be encouraging customers to get into an unsupportable mess if the upgrade goes badly. If there's no offline_db for the master, it's not ready for an SDP upgrade with the script.
There is the journal rotation at the beginning that helps, though.
The offline_db checks can be skipped by appending this to the end of /p4/common/config/p4_N.vars:
export VERIFY_SDP_SKIP_TEST_LIST=offline_db
That enables you to upgrade a replica without an offline_db (if you use -M), since on a replica it doesn't try a journal rotation there. But it won't work on a master, since (as you noted), that won't prevent the journal rotation on the master from being tried and resulting in a failure.
These seems like something that really shouldn't be allowed with the script. The script is all about encouraging/requiring best practices, like having a healthy offline_db before starting an upgrade, and also enforcing a degree of simplicity in the process by verifying rigid start conditions. It's of course possible to have a procedure that does a manual journal rotation and a manual 'p4d -xu' to upgrade without doing it the way the script requires. And since that scenario would be an edge case, I am thinking that might be preferred, rather than to have the script allow an upgrade to start that could go sideways without a clear recovery path.