I’m delighted to inform you all that Sentry v10 is now available in beta over at the onpremise repo. The beta is only intended for fresh installs as there’s still work to carry over some of the event data from the 9.1.2 release.The beta now has support for migrating old events and databases automatically but it is strongly recommended to back up your old Docker volumes first. If you’ve been watching, you may have noticed the ongoing work on the v10 branch and pull-request, along with our nightly Docker images, pushed to Docker Hub per each commit on getsentry/sentry master. All this was to enable using v10!
As you may have noticed, we are exclusively focusing on our Docker flow as we have indicated earlier in our docs (Python flow is deprecated). The great news is, you can now install any commit from master by running SENTRY_IMAGE=getsentry/sentry:<commit_sha> ./install.sh on our onpremise repo.
Please share your experience and feedback so we can improve things. We’re also curious about what you think about being able to run Sentry off of any commit.
Not yet but very soon Summary: anything available on sentry.io which was not available on 9.1.2 such as ability to connect to symbol servers, uploading pdb files, cross-project events view etc.
Ah, my bad. Something that should be turned off, seems to be on. I’ll see if I can turn it off It thinks you are in dev mode since your url-prefix is localhost
I’m just starting out with Sentry. I cannot upload source maps for a release. I’m using pretty much the unmodified configuration. When uploading source maps the error in the “internal” project is “Permission denied: /var/lib/sentry/files/36” (plus of course some trace information).
Do I need to mount the /var/lib/sentry/files directory in docker somehow? What permissions should it have?
Edit: Nevermind, I fixed it by starting a container with docker-compose run --rm web bash -l and then doing chown sentry:sentry /var/lib/sentry/files in that container. That path is already a mounted volume in the default configuration, so the permission change carries over and persists even for the container that’s running the server.
I ran out of disk space the first time I tried to run ./install.sh, which might have caused some weird configuration state. I did docker system prune -a -f before retrying, but now that I think of it I don’t think that command removes volumes, so maybe the permissions was something left behind from that first try. Just guessing though.
But I’m loving the docker setup. Despite being a pretty complex application it was rather easy to setup. And since you’re dogfooding the on-premise instance with its own errors, going from “I can’t upload source maps” to finding and fixing the underlying issue was a breeze! Happy camper right here.
Great to hear these @lars, thanks for sharing! I use docker container prune && docker volume prune && docker image prune to clean almost everything (not sure if this helps at this point).
For anyone watching here, the latest commit on the on-premise repo enabled migrating events from 9.1.2! Go give it a shot if you have an older installation but make sure to back up your data first as this is still in testing phase.
Please keep sharing your feedback here
NOTE: If you have used an earlier version of v10 BETA, you may run into Kafka issues when you upgrade to latest. See this post for the solution: Kafka Error after Upgrading
And for indexing purposes I’m attaching plain text error message:
!! Configuration error: Exception: Error: REDIS_PORT_6379_TCP_ADDR (or SENTRY_REDIS_HOST) is undefined, did you forget to `--link` a redis container?
`
Fresh install, on ubuntu on vmware
After run ./install.sh I have this error on Building and tagging Docker images…
Step 1/8 : ARG SENTRY_IMAGE
Step 2/8 : FROM ${SENTRY_IMAGE:-getsentry/sentry:latest}
latest: Pulling from getsentry/sentry
Digest: sha256:0e8c77e7e2e4dea3f2d42cacbb2e5aa4a153da7fd3b20c8ea098db6c037f80e5
Status: Image is up to date for getsentry/sentry:latest
*
*
*
Step 6/8 : RUN if [ -s requirements.txt ]; then pip install -r requirements.txt; fi
---> Running in b77ada89082e
/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
Removing intermediate container b77ada89082e
ERROR: Service 'web' failed to build: The command '/bin/sh -c if [ -s requirements.txt ]; then pip install -r requirements.txt; fi' returned a non-zero code: 127
Cleaning up...
Next image - next problems
Digest: sha256:7af5a671b686fe87c37ef5e898dc5ef02f489ca4cbf289c284a8a6f8d44e27ca
Status: Downloaded newer image for getsentry/snuba:latest
---> da5cf4ba8387
Step 3/5 : RUN apt-get update && apt-get install -y --no-install-recommends cron && rm -r /var/lib/apt/lists/*
---> Running in cd07d40b36e9
W: Unable to read /etc/apt/apt.conf.d/01autoremove - open (13: Permission denied)
W: Unable to read /etc/apt/apt.conf.d/70debconf - open (13: Permission denied)
W: Unable to read /etc/apt/apt.conf.d/docker-autoremove-suggests - open (13: Permission denied)
W: Unable to read /etc/apt/apt.conf.d/docker-clean - open (13: Permission denied)
W: Unable to read /etc/apt/apt.conf.d/docker-gzip-indexes - open (13: Permission denied)
W: Unable to read /etc/apt/apt.conf.d/docker-no-languages - open (13: Permission denied)
E: Error reading the CPU table
Removing intermediate container cd07d40b36e9
ERROR: Service 'snuba-cleanup' failed to build: The command '/bin/sh -c apt-get update && apt-get install -y --no-install-recommends cron && rm -r /var/lib/apt/lists/*' returned a non-zero code: 100
Cleaning up...
I am quite sure your Docker environment has some permission issues or something worse. Those errors are coming from building Docker images with nothing special in them.
Another possibility is your Docker Hub mirror delivering you defective images.
Summary: anything available on 
