I think this makes sense.

Very nice!

There's a few issues with the configuration of these indexer clients:

Is there anything preventing swh-auth from using next= instead of next_path=?

In D8420#219396, @anlambert wrote:

In D8420#219364, @anlambert wrote:

In D8420#219363, @olasd wrote:

While you're refactoring this, is there a reason for not using the default REDIRECT_FIELD_NAME from django.contrib.auth ("next") for the login/logout views, instead of "next_path"? This would save us from having to override it on every user_passes_test call.

Oh I missed that django setting, let me check.

That's much better indeed, thanks ! Diff updated.

While you're refactoring this, is there a reason for not using the default REDIRECT_FIELD_NAME from django.contrib.auth ("next") for the login/logout views, instead of "next_path"? This would save us from having to override it on every user_passes_test call.

Thanks! I guess this needs a version bump on swh.core in requirements-swh.txt

Indeed this seems useful; I've made a couple of naming nitpicks, but I don't care very strongly about them.

Rebase

I agree that the UX of switching branches from a release to another on snapshots of PyPI origins is not good.

Thanks for looking into this!

Thanks.

Neat

Cool stuff, thanks!

Thanks!

I've deployed the quiesced scrubbers (v0.1.0) on both staging and production.

Thanks for checking the swh.core code, and sorry for the handwringing!

This is missing the database upgrade script

Maybe use the same metric with an operation="check_hashes"/"check_references" tag?

Meh. Seems like some default from prometheus-statsd-exporter unexpectedly does the right thing then.

We don't use statsd namespaces, which use dots in metric names and aren't really compatible with the way we set up the prometheus statsd exporter.

I think you've forgotten to remove the erb template :-)

Thanks, this would be a welcome change.

That seems like a plausible change, thanks!