Package Details: sentry 9.1.2-1

Git Clone URL: (read-only, click to copy)
Package Base: sentry
Description: Python-based realtime logging and aggregation server.
Upstream URL:
Licenses: BSD
Submitter: zancarius
Maintainer: zancarius
Last Packager: zancarius
Votes: 14
Popularity: 0.85
First Submitted: 2012-11-04 17:15
Last Updated: 2019-08-31 02:03

Pinned Comments

zancarius commented on 2020-01-23 21:38

I have spent some time exploring options for upgrading this PKGBUILD to the latest version of Sentry and have encountered blocking changes that do not appear to have a clear resolution.

Currently, there were two PKGBUILDs that provide our required Clickhouse dependency but neither of these build successfully. Near as I can tell, some of Clickhouse's upstream dependencies have known issues that as yet have no resolution outside attempting to patch either Clickhouse or wait for the upstream developers to address these deficiencies. This is not something either myself or the maintainer(s) of the Clickhouse PKGBUILD(s) can address (not easily, anyway).

Consequently, I will be updating this PKGBUILD, bumping the pkgrel in effort to increase the visibility of this issue. We will be holding Sentry at its current state until we have a clear path forward.

If you need Sentry 10.x.x in your environment, consider installing their official Docker packages. This is the currently recommended method for installing Sentry.

zancarius commented on 2020-01-17 06:45

Sentry v10.0.0 is out, but I will not be upgrading this package for some time. In fact, I'm not sure when an upgrade will be available because the number of additional service dependencies has since exploded.

To illustrate, Sentry v10.x now depends on:

  • Zookeeper
  • Kafka
  • Clickhouse
  • Snuba

I don't believe Snuba can be disabled in Sentry post-v9.1.2. If this is true, then this means that Sentry now has an implicit dependency on the JRE which may be prohibitive for those users who are running Sentry on lower end hardware or memory-constrained environments.

The official installation guide recommends installing the on-premise edition of Sentry via Docker and advises against source installation, which is what we're doing here.

This leaves us with a couple of options (plus a third thrown in as an either/or):

1) Upgrade anyway and add a host of other dependencies to the PKGBUILD that may surprise some users. Given that Sentry is a complex piece of software to install, this will only add to the complexity and will require additional packages, configuration, etc., that will need to be completed before Sentry can even be upgraded. (The migration process moves events from the database into Snuba, for example.)

2) Cheat and take the easy way out; deprecate this PKGBUILD and point users to the official Docker images. There's no point trying to wrap the Docker images in a PKGBUILD.

3) Rename this package to something like sentry9.1, freezing it at this version, and then pick options #1 or #2.

When I have some time this weekend, I may ask around for advice. There's no easy solution in this case, and I know from past experience with this package that there are some users who may be uninterested in running Sentry v10 if it requires configuring at least 3 other services. I will leave this package flagged for the time being in the hopes users of this package check here.

Latest Comments

« First ‹ Previous ... 3 4 5 6 7 8 9 10 Next › Last »

Mastacheata commented on 2016-04-20 01:16

You already accounted for the config.yml file to be present, but you seem to have missed the adjustment of the config parameter.

In order for settings in config.yml to be applied, sentry must be started with the config parameter set to the parent directory. (/etc/sentry in this case)
Previously you had to set this to the file.

Even though the config.yml doesn't do that much harm to this date (they simply haven't migrated any of the critical settings there yet), it caused me a major headache to find out why my sentry was ignoring the mail.use-tls setting entered in the config.yml while adhering to the EMAIL_USE_TLS directive in the (with the downside of having a deprecation notice on top of the sentry webinterface).

I submitted a PR to your github repo.

mitchhentges commented on 2016-04-12 19:47

These are really good points. That makes sense, thanks guys!

zancarius commented on 2016-04-12 17:23

It's my belief that automatically applying database migrations is the antithesis of Arch philosophy (although there are counter-examples to this). In addition to the reasons codekoala touched on, it's generally a good idea to backup your existing database prior to upgrading, and I can't see an effective way to do this automatically with the tools Sentry provides in a manner that would appease all users (multiple DBMS support, backup placement, etc).

Having said that, the GitLab PKGBUILD in the AUR [1] is the only one I'm aware of that actively applies database migrations, handles backups, etc., during the upgrade process. GitLab is a fairly complex system to install, but being being a RoR app it provides a few helpful utilities for doing much of this automatically (including backups) and is therefore relatively self-contained (to the best of my knowledge, Sentry only provides migration support out of the box). However, I'm not completely convinced the extra complexity in a PKGBUILD install script is warranted. It's more to maintain, it's more that requires testing following each upgrade, and a failure of the upgrade process could be harmful to your data. I've had Sentry migrations fail (6.x or 7.x to 8.x failures) or halt when they want to remove unused roles, requiring manual intervention anyway.

I guess this is just a long-winded way of saying that my philosophy is analogous to what codekoala touched on: I see the PKGBUILD and its install/upgrade process as a way of installing (or updating) the application. I'm reluctant to touch your data as I feel that's your responsibility. I can't account for all use cases where Sentry is installed, and some of the larger deployments generally require planning before an upgrade. Automatically doing *anything* could introduce errors into this process, so I took the more conservative route of printing (hopefully) helpful notices following an upgrade detailing what you need to do before restarting Sentry (and reminding you to take backups of your database!).

Incidentally, the official PostgreSQL packages don't upgrade your installed databases automatically either, as an example of an official package and its behavior. You're expected to install postgresql-old-upgrade and follow the instructions on the wiki [2]. Hence, I believe this PKGBUILD follows more closely with the official philosophy, of which I can think of no examples that do anything without manual intervention (this is why I dislike Debian distributions--they start services automatically after installation without so much as a chance to configure them).

You're welcome to create an issue on the GitHub repository containing this PKGBUILD [3] where we can discuss this further. I'm open to making things easier (perhaps the instructions we print following an upgrade are too verbose and need to be rendered more concise?), but I also hesitate to do anything that might cause headaches for deployments that have already been installed and may have automated tooling and review processes that assist them during an upgrade.


codekoala commented on 2016-04-12 15:48

Here's another scenario: let's say you upgrade a database from one major version to another. For example, if you upgraded PostgreSQL 9.4 to 9.5, would you want the package to worry about migrating all of your data to the new version's format? While it would be convenient, it could be a very destructive operation that you'd want more control over. Say you have custom extensions for 9.4 that have not yet been updated or compiled/installed for 9.5. Bad things would happen, and you'd likely lose data.

Upgrades dealing with data are generally left to be manual operations. The migration command that sentry provides is about as automatic as I'd personally prefer to see. In the case of Firefox, it upgrades itself regardless of platform. It's built into Firefox, not into the Arch package.

mitchhentges commented on 2016-04-12 15:42

Does it go against the Arch way? Looking at the functions that are allowed in the install script, it appears that handling upgrades are one of the core features of a PKGBUILD [0] (install, upgrade, remove).

I'd argue that this isn't the same as enabling or starting services, because running an upgrade script is strictly a one-time operation. I feel that it's very similar to an install script.

Finally, or paying attention to what's being installed or upgraded: this is the only package that I have needed to manually execute a command for upon the application being upgraded. Whenever I upgrade Firefox, I don't need to manually make it update its local schema.

At the same time, I'm not maintaining my own AUR packages, so this is mostly an outside opinion. Perhaps there are other packages which require manual upgrades.


codekoala commented on 2016-04-12 14:35

@mitchhentges it's certainly possible, but it goes against the arch way. No (official) packages that I'm aware of automatically enable/start services, and this falls into the same category in my opinion.

The expectation for us as arch users is that we pay attention to what's being installed or upgraded. The informative message that this package already provides after installation is exactly what it should be.

mitchhentges commented on 2016-04-12 12:23

Is it possible to run a script on upgrade? It took me a little bit to realize that all my requests were failing: turned out I needed to run
./bin/sentry --config /etc/sentry/ upgrade

It would be awesome if this package could run this command itself.

zancarius commented on 2016-04-11 07:30

I'll be posting the updated PKGBUILD tomorrow 20160411, possibly around noon (MDT). I haven't had time yet to examine some of the upstream changes including uWSGI's new "die-on-term" option. The "correct" solution is to probably continue sending a SIGINT until uWSGI 2.1 is released and Sentry updates to it.

zancarius commented on 2016-03-15 19:11

Okay, bumped version to 8.2.3, including @mitchhentges' SIGINT fix for uWSGI. If uWSGI changes this behavior, it might be necessary to remove this in the future. Thus, a healthy dose of caution is required for each update from this point onward.

We may consider moving to systemd.targets for Sentry. I was considering adding that in this patch, but it occurred to me that the possibility of using different DBMSes causes a bit of a problem insofar as target dependencies go (and I'm not sure what the best solution is in this case).

On the other hand, is launching two separate services (sentry + sentry-celery) problematic/annoying enough to warrant a

zancarius commented on 2016-03-15 16:52

Oh gosh, I'm an idiot. I've been working with uWSGI, too, for some of my own projects and ran into this exact issue, but apparently the idea never once occurred to me to add this to the unit files for Sentry.

I have absolutely nothing in my defense other than to say that reading the uWSGI docs for unrelated reasons sometime in the last month or two must've flushed that *weird* behavior out of my conscious memory.

Good catch, @mitchhentges, and great detective work! I'm thinking the systemd unit fix is the best option!

I'll be getting to your PR later today when I have some time. Thanks!