This PR removes the 2 old triage labels replaced with new ones:
1. `Status: Accepted` -> `Status: In Progress`
2. `Status: On Hold` -> `Status: Backlog`
We've been leaving onpremise master with the latest release, instead of nightly builds for 2 releases now. Even if the post-release script runs, it bumped the versions to nightly on the release branch, making it effectively a no-op. This should be addressed in Craft via getsentry/craft#115 but until then, we need this extra line.
These were looked over when they were added. This is not a big deal as running `docker-compose up -d` spins up all services but this fix is for correctness sake, especially for folks using this repo as a basis for more complex setups.
We used to build local images for Sentry services to be able to
include required plugins in the image. With this change we instead
do this in a custom entrypoint script and use the volume `/data`
to store the plugins permanently.
This should resolve many issues people have around building local
images and pushing them to places like private repositories or swarm
clusters.
This is not 100% compatible with the old way but it should still be
a mostly transparent change to many folks.
* ref(requirements): Add min CPU requirement, relax soft RAM
Adds minimum of 4 CPU cores requirement as anything below will perform quite poorly even on lower loads. Relaxes the soft RAM requirement from 8000 MB to 7800 MB as even when there is 8 GB RAM installed, the system reserves some of it to itself and under reports the amount.
* pass on CI with soft limit
Fixes the issue where we set an invalid option, `github-app.extended-permissions`, instead of the correct one, `github-login.extended-permissions`. Some people mentioned this warning earlier but never clearly enough to point that it was coming from our default settings suggestions.
When trying to install self-hosted Sentry on Google Cloud Compute container-optimized OS, I hit an issue where the disk space was not sufficient to even build local images. Given Kafka and Clickhouse are also quite disk-intensive, it makes sense to add this to the docs.
Opted not to add an automated check for this as it is not easy to determine the path Sentry installation will consume, hence the free space there.
Fixes#823. In `install.sh` we build a local sentry image that is used by many services from using the build context under the `./sentry` directory. To avoid building this image multiple times, we also give it a specific name which is referred from multiple services. The issue is, we also run `docker-compose build --parallel` which creates a race condition when building this image as `docker-compose` doesn't check whether the image is already there or not. This is the root cause of all these random failures: an unsurprising race condition.
Based on my reading, this error comes from urllib3.
https://urllib3.readthedocs.io/en/latest/advanced-usage.html
>The behavior of the pooling for ConnectionPool is different from PoolManager. By default, if a new request is made and there is no free connection in the pool then a new connection will be created. However, this connection will not be saved if more than maxsize connections exist. This means that maxsize does not determine the maximum number of connections that can be open to a particular host, just the maximum number of connections to keep in the pool.
I think the ideal solution would be to add `retry` and `block` options to [docker-py](ce2669e3ed/docker/transport/unixconn.py (L58-L70)) but that's a long shot.
