frontend: Enforce upgrade policy
Created by: tsenart
This commit changes the frontend to enforce our upgrade policy on
startup. A versions table is introduced, where the latest seen version
of a service in the Sourcegraph architecture is stored.
For the frontend, this is done on startup, before database migrations are run. If an admin violates our upgrade policy, the frontend will shutdown with a descriptive error, pointing to our documentation.
In a future PR, we'll ensure our upgrade policy is respected by
other services. This will be done by sending the service's version
along to the frontend on calls to api.InternalClient.WaitForFrontend
during a service's startup procedure, and having the frontend respond
with an error if the upgrade is invalid, which the service should handle
by logging and shutting itself down.
Fixes #7702 Follow-up in #8382
Merge request reports
Activity
Created by: tsenart
One question: How do we deal with version roll back? Should we prevent that in hard way (i.e. fail to start as if it violates the upgrade policy) and make the admin contact us for support?
That's a great point! I think we should allow all roll-backs. Will make the change.
Created by: tsenart
I'm still not 100% convinced that being strict on all services is the best thing, vs just enforcing that when there is an upgrade it only jumps 1 minor version.
This PR only affects frontend. I added support for all downgrades and roll-backs. Are your concerns addressed?
Created by: slimsag
Apologies for the major delay in my review -- this looks great! In specific the described behavior LGTM, and the code also LGTM from a quick glance (but I didn't dive into it too deeply).
Was there an issue with the implementation given @keegancsmith reverted above, or was that revert not from
master?Created by: unknwon
@slimsag I think the commit is not from
masterbranch. FYI , this was the commit to fix the CI failure: https://github.com/sourcegraph/sourcegraph/commit/0adf4e2427224526f9cbed901327963752fc1981
