This fixes a serious bug in install.sh where it ignored externaly set env variable values such as `SENTRY_IMAGE` in favor of the ones defined in `.env`, essentially making all our e2e tests usless.
Our relay connection wasn't behaving correctly because of some missing config in our `sentry.conf.py`. Also, we didn't have the performance module enabled because of a missing feature flag.
That's why an entry in the documentation regarding this would be nice.
@xbenjii reported the following error on #629:
>You requested maxclients of 10000 requiring at least 10032 max file descriptors.
Increasing this limit by default makes sense to make Redis more available to heaveier loads.
We need `docker-compose ps -a` for CI so we were already using 1.24.1, this aligns the rest with that.
For Docker, there are a bunch of network-related fixes in 19.03.12 and prior (DNS fallback and IPv6 advertising) that we'd like to have to see if they are going to fix some reported connectivity issues w/ onpremise.
Fixes https://github.com/getsentry/onpremise/issues/672
I split this PR up into 4 commits. The first one is the bare minimum for the issue. The rest are just consistency corrections that we neckbeards at irc://chat.freenode.net/%23bash would always make.
Fixes#502 and applies the suggestions from there:
- Number of partitons=1 (from 40)
- Log retention to 1 day (from 7 days)
These settings should be more suited towards the scale this repo is intended for.
NOTE: The partition count change will only affect new installs unless `sentry-kafka` and related volumes are cleaned.
GitHub team pointed us to docker/compose#3586 as the likely root cause and some digging around revealed got us to https://git.io/JUn7p as a potential fix, which we are trying here.
This is for the onpremise release on Sept 15th.
The new migration system has a migration to handle recreating the
transaction table if the old one is present, we no longer need to do
this in `install.sh`.
Closes#616, supersedes #651
Adds an option to reduce max memory usage of Clickhouse server. Sets it to 30% of all available RAM as the default.
Co-authored-by: Renaud Chaput <renchap@gmail.com>
Fixes an issue where we recommend adding TLS terminating Nginx into the docker-compose file. This is no longer recommended as we already have an nginx instance there for routing purposes.
Fixes#653.
This continues on the ideas from #607. By "downtime" here I mean "not accepting events" - web, smtp and background processes are out of scope.
This PR adds a `--minimize-downtime` option to install.sh. This options changes the behaviour of the script by:
1. keeping nginx and relay running until the very end,
2. disabling cleanup on exit and failure,
3. explicitly reloading nginx configuration,
4. and starting the whole cluster at the end.
The results are promising: no downtime if relay version doesn't change, and only a second when it does. So far this was only tested with a curl loop, so I'm still not sure if Relay flushes the events to Sentry before getting recreated by `$dc up`.
If the release action is run without an explicit version in the same calendar month more than once, all of them will try to release the same version where the patch version is set to 0. This is never the intended action: if we are making a new release in the same month where an old one exists, it is 100% a patch release.
This PR automatically implements patch version increment based on existing versions.
This change allows one to override any Sentry service image, mostly for testing purposes. It also removes the SENTRY_VERSION variable as docker-compose makes it very hard to cascade default values for these. Next step is to have integration tests in getsentry/snuba and getsentry/relay (and possibly for getsentry/symbolicator) for getsentry/onpremise using this PR.
Also related: #596.
Without the consumer-group option, transactions consumer and events consumer will compete for messages on the same topic and usually events win, which is the first one. This may cause some data loss for performance and make it seem not work.
Should address https://forum.sentry.io/t/perfomance-tracing-for-sentry-itself/10405/5?u=byk
