I think I've mostly coerced sentry, at url https://sentry.softwareheritage.org/, into working. I used the opportunity to start refactoring the way apache is handled in our puppet environment, as well as slowly migrating some vhosts to Let's Encrypt.

Rather than depend on the counter table, which is only updated every so often and which doesn't account for potential holes in origin ids, we should use something more reliable to get a random row like the SQL 2003 tablesample clause implemented in PostgreSQL.

To future-proof this, I suggest switching the logic to have a map between error codes and log levels in the error_cb function; I'm sure we'll want to tune other messages, and I'd prefer mapping this to a debug level log message rather than silencing it completely.

The new virtual machine for sentry, riverside.internal.softwareheritage.org, has now been installed.

FWIW the expected automatic renewal happened and the updated cert has been deployed on the subsequent puppet run.

Looks good to me.

This is crying for a "lazy-loaded snapshot object" abstraction in swh.storage, but I guess that's a good step up from the status quo :)

Thanks for the investigation!

In D2383#56176, @olasd wrote:

Cycle detection in snapshots is supposed to be handled in the snapshot_identifier function; that's why it's called in a loop when generating the snapshot id.
If there's a bug here it should be fixed in that function (and a regression test should be added).

Cycle detection in snapshots is supposed to be handled in the snapshot_identifier function; that's why it's called in a loop when generating the snapshot id.

I'm just a tiny bit worried that this "swh extension" might clash with something that upstream git implements, if we reuse git terminology.

Rebase

Still install gunicorn