>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. On Fri, Oct 19, 2018 at 10:41 AM Rawlin Peters <[email protected]> wrote: > On Fri, Oct 19, 2018 at 9:21 AM Gray, Jonathan > <[email protected]> wrote: > > > > I'm -1 on this. In the event you're doing some massaging of commits and > migrations are missed due to the dependence on timestamps in filenames, > "goose down" allows you to fix the data. > > I'm not saying we should totally get rid of `goose down` altogether. > In the event that you're not running standard releases and are doing > stuff like cherry-picking commits into a custom release, `goose down` > should still be available as a riskier avenue for attempting to get > back to a good state but should not be the standard process. Manual > hacking of the goose DB metadata is another alternative to that as > well which would leave the real data alone. > > - Rawlin >
