SDP-625
Closed
upgrade.sh needs to bounce p4d for multi-instance patch-only upgrades.
When a patch-only p4d upgrade is done in a multi-instance environment,
the SDP upgrade.sh script will bounce only the p4d for the first
instance. For instances processed after the first, upgrade.sh does not
realize that the subsequent instances require a bounce of the p4d
service because the Major Version Symlink (e.g. 'p4d_2020.2_bin') is
already correct and pointing to the latest patch binary.
Correct behavior would be to do a 'p4 info' check against the live
running p4d (or p4broker/p4p), and if it is different from version
indicated by the symlink AND the service was up and running at
the start of processing, bounce the service.
The workaround is simply to bounce p4d manually for instances upgraded
after the first.
Digression: Long ago SDP was designed with the assumption that, on
any given machine, if a p4d/p4broker/p4p binary was patched, all
instances on that machine would commit to taking the patch at the
next opportunity to bounce the service. This was done to encourage
patch upgrades, while still retaining some flexibility in controlling
when the upgrades are done. (This has always come with the caveat
that an unplanned service restart will also cause the new binary to
go live; that characteristic remains, and ultimately is deemed more of
a Good Thing than a risk).
Note that none of this applies to major version upgrades, which
must always be explicitly selected on a per-instance basis.
When a patch-only p4d upgrade is done in a multi-instance environment,
the SDP upgrade.sh script will bounce only the p4d for the first
instance. For instances processed after the first, upgrade.sh does not
realize that the subsequent instances require a bounce of the p4d
service because the Major Version Symlink (e.g. 'p4d_2020.2_bin') is
already correct and pointing to the latest patch binary.
Correct behavior would be to do a 'p4 info' check against the live
running p4d (or p4broker/p4p), and if it is different from version
indicated by the symlink AND the service was up and running at
the start of processing, bounce the service.
The workaround is simply to bounce p4d manually for instances upgraded
after the first.
Digression: Long ago SDP was designed with the assumption that, on
any given machine, if a p4d/p4broker/p4p binary was patched, all
instances on that machine would commit to taking the patch at the
next opportunity to bounce the service. This was done to encourage
patch upgrades, while still retaining some flexibility in controlling
when the upgrades are done. (This has always come with the caveat
that an unplanned service restart will also cause the new binary to
go live; that characteristic remains, and ultimately is deemed more of
a Good Thing than a risk).
Note that none of this applies to major version upgrades, which
must always be explicitly selected on a per-instance basis.
- Status
- Closed
- Project
- perforce-software-sdp
- Severity
- B
- Reported By
- C. Thomas Tyler
- Reported Date
- Modified By
- C. Thomas Tyler
- Modified Date
- Owned By
- tom_tyler
- Component
- core-unix
- Type
- Bug