This is a small polishing on the storage migration and storage rollback
rake tasks. By aborting a migration while a rollback is already
scheduled we want to prevent unexpected consequences.
Rollback is done similar to Migration for the Hashed Storage.
It also shares the same ExclusiveLease key to prevent both happening
at the same time.
All Hashed Storage related workers now share the same queue namespace
which allows for assigning dedicated workers easily.
We are adding sidekiq workers and service classes to allow to rollback
a hashed storage migration. There are some refactoring involved as well
as part of the code can be reused by both the migration and the rollback
logic.
Specs were reviewed and improved to better cover the current behavior.
There was some standardization done as well to facilitate the
implementation of the rollback functionality.
StorageMigratorWorker was extracted to HashedStorage namespace were
RollbackerWorker will live one as well.
In the previous code, we locked the project during the migration
scheduling step, which works fine for small setups, but can be
problematic in really big installations.
We now moved the logic to inside the worker, so we minimize the time a
project will be read-only. We also make sure we only do that if
reference counter is `0` (no current operation is in progress).
`perform_enqueued_jobs` is a Sidekiq method.
Using this method violates the Dependency inversion principle[0].
This commit replaces `perform_enqueued_jobs` with ActiveJob's abstract
method `perform_enqueued_jobs` in specs.
[0]: https://en.wikipedia.org/wiki/Dependency_inversion_principle
GitLab Bot