Upgrading

QSCS upgrades are routine. The package replaces the binary in place, systemd restarts the service, and you're done. There is no schema migration, no cache invalidation, and no required downtime beyond the few seconds of the restart.

Standard upgrade

sudo apt-get update
sudo apt-get install --only-upgrade qscs-bootstrap
sudo systemctl restart qscs
/opt/qscs/bin/qscs --version

The reported version string should match the new release.

Recommended order in a multi-node cluster

1. Pick a quiet window.
2. Upgrade thin clients first, one at a time. While one thin client restarts the others (and the master) keep serving traffic.
3. Upgrade the master last. During the few-second master restart, thin clients serve HEADLESS responses if needed, then resume normal operation when the master is back up.
4. Re-subscribe each node after a major version: sudo qscs subscribe domain <tag> then restart.

Verifying after upgrade

sudo systemctl is-active qscs        # active
/opt/qscs/bin/qscs --version          # new version
curl -i -H "Host: <origin>" http://127.0.0.1:8080/   # 200 OK with X-QSCS-Mode

And check the journal for the role-detection line:

sudo journalctl -u qscs -n 50 --no-pager | grep -E "role=|Origin reg"

Rolling back

The apt repository keeps the previous version available. To roll back:

sudo apt-get install qscs-bootstrap=<old-version>
sudo systemctl restart qscs

The configuration file format is forward and backward compatible within a major version. Before a major upgrade, back up your configuration and verify compatibility in a test environment.