Tested this in a Ubuntu VM. The output of `date` is not too pretty but at least localized (so D/M vs M/D is not confusing)
## What is the TSDB migration?
We're effectively deprecating all TSDB backends but `sentry.tsdb.redissnuba.RedisSnubaTSDB`. We cannot reasonably support any other backend due to the fact that we would have to reimplement each of the backends in Relay, which is written in a different language. Also, like with deprecating mysql support, we don't really have the capacity to support things we do not use ourselves.
## Migration
`install.sh` should rewrite your configuration automatically and define a cutover date such that no data is lost. Before the cutover date, data is written to two backends at once, Redis and Snuba, and read from one, Redis. After the cutover date, event-related metrics will be read from Snuba which matches what we have on sentry.io.
## Manual migration guide for TSDB
In case `install.sh` is unable to migrate your files you will be given basic instructions on the console that essentially tell you to completely delete all TSDB config and paste the new, standard one. If for some reason you cannot say goodbye to your existing TSDB config, please create a new issue in this repo and cc @untitaker on it.
This PR disables checking for the SSE4.2 flag, which may not be present if the server is running in a VM even if SSE4.2 is in fact available to use (ClickHouse/ClickHouse#20). The KVM check was obtained from a [comment](https://github.com/ClickHouse/ClickHouse/issues/20#issuecomment-226849297) in that issue.
If SSE4.2 is not actually available in the VM, then the installation script may fail in an unpredictable way. Perhaps we can add a keyword argument to the script to let the user decide if they want to skip the check.
This patch does two things:
1. Separate creating of Relay credentials from syncing them to Sentry config
2. Has a more flexible Relay credentials check and sync: look for the quoted public key in the config file, if it is there, assume this must be correctly set as it is very unlikely to have that random key in a different context with quotes around. The second one is to allow having other whitelisted relay keys by using an append method when adding the new key.
We regularly prune old Google Cloud Build images and also GCB registry is not accessible to everyone all the time (firewall settings, being in China, etc.)
Fixes#445.
* feat: Add snuba outcomes consumers to setup
* fix: Rename all references of snuba-consumer
* ref: Rename back to snuba-consumer
* fix: Change auto-offset-reset
* fix: Attempt to fix CI
This follows the best-practice of mounting the config folder as a volume and removes the need to rebuild sentry images for config changes. Partially addresses #314.
This addreses multiple questions raised about how to install a specific version of Sentry or using specific versions for images such as #378, #355, #348, and #326.
Update exit -1 to exit 1 in line with best practices
Fixes premature exit of the script when checking for sse42 support. The
script would exit before displaying the reason for failure to the user.
With getsentry/snuba#709 merged, we no longer need to randomly try forever creating Kafka topics, which were a prerequisite for creating Clickhouse tables. This patch also removes the preceding (and obsolete) `docker-compose up` statement which was used to "speed up" the `snuba bootstrap` command in the hopes to fix it.
