Currently in sentry, both SnubaSearchBackend and EventsDatasetSnubaSearchBackend exist, and they are the same.
This just points to the new (renamed) class so we can delete SnubaSearchBackend from sentry, as we only left it in to transition getsentry & onpremise.
Since we are [moving the eventstream into a proper db migration](https://github.com/getsentry/sentry/pull/16226), we need Snuba and its friends ready at the time of `sentry upgrade` command. This patch does exactly that.
Co-authored-by: Lyn Nagara <lyn.nagara@gmail.com>
This change makes the install script create a new install log file, `sentry_install_log-<ISO_TIMESTAMP>.txt`, for each run and records all the output there for future reference.
Plugs all the holes (VOLUME defs) in the images we use so they at least persist across runs/restarts for things like random logs or SMTP spool. This also fixes symbolicator_cleanup service not having access to symbolicator data.
This patch introduces the following fixes to uWSGI config which
was not set up correctly to be used publicly (not behind a router,
load balancer, proxy like nginx etc.):
- Use `http` option for a front-proxy
- Set protocol back to `uwsgi` due to above
- Prevent forced socket binding to `uwsgi` due to protocol change
above (https://git.io/fj7Lw)
- Turn on "keep-alive" support
Should fixgetsentry/sentry-cli#40.
This adds a fully automated `install.sh` that does the following:
- Checks minimum Docker and `docker-compose` versions
- Checks minimum RAM available to Docker containers
- Removes potential user errors in install steps
Django 1.7 already defaults to `True` for this and in Django 1.8, which
is what the latest Sentry uses, the option is removed and causes a DB
connection error so dropping it to fix git builds.
Remove a match-all glob pattern. It looks like some non-git tools read the `*,cover` as `*` and `cover` separately and basically ignore all files. Even though this is not really a problem with the repo itself, I think the change is still valid, considering `*,cover` looks like an invalid rule anyway.
_____
Background:
(__This part is vim-specific__)
For a while now, my Neosnippet configuration has been going for a toss when working on our fork based off of this repo. I see a message similar to the one reported [here](https://github.com/Shougo/neocomplcache.vim/issues/468), but my vimrc configuration is as per the documentation available in the plugin docs. I finally spent enough time to debug this today, and it turns out this issue was happening *only* in this repo and nowhere else. So I went through the files that might've to do anything with folder-specific configuration (think dotenv, editorconfig etc.), and turned out `.gitignore` was the only such file; I use [this plugin](https://github.com/vim-scripts/gitignore) to load the gitignore rules into the `wildmenu` completion and the `*,` part basically (from what I understand) removes most of the load path configuration from vim 😄. I'll probably have to go make a change in that plugin as well though.
