Package Details: sentry 8.3.1-2

Git Clone URL: (read-only)
Package Base: sentry
Description: Python-based realtime logging and aggregation server.
Upstream URL:
Licenses: BSD
Submitter: zancarius
Maintainer: zancarius
Last Packager: zancarius
Votes: 6
Popularity: 0.359885
First Submitted: 2012-11-04 17:15
Last Updated: 2016-04-20 03:18

Required by (0)

Sources (3)

  • sentry-celery.service
  • sentry.install
  • sentry.service

Latest Comments

Mastacheata commented on 2016-04-20 12:16

Ohh, sorry. To me it looked like you read my comment and thought migration as in migrate away. (Which is a very common misconception if you encounter that term for the first time)

> At present, I can't find any immediate need to migrate specific configuration values from the old `` style config with the exception of Redis (a recent addition).

The Mail settings are even more important. Redis can still be configured in the without the UI complaining, but if you configure the mail settings in the python file, you'll get deprecation notices in the Web Interface.

zancarius commented on 2016-04-20 03:35

Okay, I've pushed the new PKGBUILD (same version; the `pkgrel` is the only thing that's changed).

If you're coming upon the comments here because you're somewhat perplexed or concerned about the deprecation of MySQL support as indicated in the upgrade notes, you'll need to read the official stance in the Sentry changelog for 8.0 [1]. There isn't much we can do about this, and you'll need to plan accordingly. I've linked some tools in the upgrade text that might help you but bear in mind that using them is completely unsupported. In addition, you're strongly encouraged to read the PostgreSQL user's guide which details migrating your data from MySQL to Postgres, concerns, and likely problems [2] (it's possible but only you can decide if it's worth the effort). There are other scripts out there that can assist you with migrating your data, but I'll leave using them as an exercise to the reader. I'm reluctant to get into the politics of it here, but you really ought to use a Real™ DBMS if you're not already--in particular, PostgreSQL has support for DDL changes within a transaction, making schema migrations relatively painless if something should go wrong (MySQL doesn't and therefore has the propensity to cause many sleepless nights--ask me how I know).

Otherwise, thanks to the efforts of mastacheata, the last vestiges of our Sentry package's dependencies on the old configuration style are mostly on their way out. You still have to use it, but the initialization process and instructions have been updated accordingly. (Note: The official documentation uses envvars for conveying configuration location; I'm yet undecided whether or not we'll end up using those instead.)

At present, I can't find any immediate need to migrate specific configuration values from the old `` style config with the exception of Redis (a recent addition). If this concerns you, you may want to generate a new configuration using `sudo -u /opt/sentry/bin/sentry init` where appropriate or follow the upgrade instructions. Be aware that you'll need to keep your secret key (now contained in /etc/sentry/config.yml), otherwise all of your existing login sessions are likely to fail.

As usual, I cannot stress enough the necessity of backing-up your database and test the installation on a development machine before deploying this package. If you encounter difficulties, post them here or open a ticket on the repository containing this PKGBUILD [3].


zancarius commented on 2016-04-20 02:42

*face palm* I'm well aware of what what migrations are (currently, I'm developing some relatively large Flask-based applications with my preference being SQLAlchemy), but there are tools to migrate data away from different DBMSes (with different degrees of success). Hence the link in my earlier comment.

In this context, though, I'm referring to migrating 1) existing configurations (this needs research) and 2) possible options for migrating data away from MySQL for those users who may have done that.

I'm not referring to schema migrations. Perhaps the appropriate term is "export" but you're still dealing with migrating data away from one platform on onto another.

For what it's worth, I've actually been running Sentry under MySQL for quite some time. The Django ORM and Sentry's existing migration utilities and libraries have been working fine for this purpose (with the exception of one or two changes I've had to make recently to individual migrations).

Mastacheata commented on 2016-04-20 02:32

Re 2)
Migration has nothing to do with switching database systems in this context. A migration is basically a script or program that performs changes on the database (structure). Basically these scripts are built so that you can have a version control for your project's database structure. For more information see here:

Sentry is known for modifying their database structure very often. These changes between program versions would usually be performed by the upgrade command. However as of sentry 7 only changes to postgres are automated (run upgrade command and be happy).
You CAN continue to use mysql or sqlite since the code for reading and storing data is pretty easy to keep platform independent. But you need to perform any changes made to the postgres structure in your mysql or sqlite db by hand. (i.e. Rename column x in table y or change the data type or add a new index, or or or)

Thanks for looking into this so quickly.

zancarius commented on 2016-04-20 01:32

1) I'm currently looking at the PR request. I'll merge it, but I need to see what may be required in the future for existing users for the config migration.

2) Dropping MySQL-related notices would probably be pertinent. I'll freely admit I don't follow Sentry's release notes all that closely. (Shameful.)

As far as database migration from MySQL to Postgres, I think that's the user's responsibility (and they'll have to decide how they want to handle migrating away from MySQL, if they're using it). Sentry AFAIK is a Django app and there are tools that may help [1], but I don't think that's something this package should be concerned with--even if someone has been using MySQL previously.

Unfortunately, that's the nature of large "some assembly required" applications that require additional configuration and work out of the box.


Mastacheata commented on 2016-04-20 01:23

One more thing: Does it make sense to keep the mysql/mariadb and sqlite bindings mentioned here? The sentry team stopped maintaining the database migrations for these backends in version 7 and announced to drop support completely in the future.

That means any database changes made since the announcement will work automatically using the upgrade command for postgres, but will have to be made by hand using only the postgres sourcecode for any other backend. (Yes you really need to look at their postgres migrations and find out what it does there and how to apply that in MySQL/SQLite Syntax if that's even possible at all)

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.

All comments