On Fri, Oct 19, 2018 at 10:48 AM Robert Butts <[email protected]> wrote: > > >you can do a safe, immediate rollback of the upgrade to bring the service > back to a known working state > > But the previous database isn't necessarily still a working state. Any data > changes involving origins or clients will break the delivery service. For > example, if a DS origin is changed by a tenant, or if a new DS is added. > Reverting to the previous copy will then break the delivery service, > because clients are expecting a new FQDN in the CDN that the DB rollback > just erased, or because clients requests are now routing to an origin that > no longer exists.
True, but in that case where the issue was not found immediately and hence probably not major, we'd probably consider hotfixing the release rather than doing a full rollback of the upgrade if lots of changes were made since the upgrade. Doing an immediate rollback via DB restore after issues are discovered shortly after the upgrade is the safest option in that scenario. But if the upgrade has lasted a week already, lots of new data changes have been made since then, and a non-major issue is discovered, then that changes the game a bit and would require assessing the risk of a full rollback vs goose down vs hotfixing the release. - Rawlin
