This is a fix for the Hashed Storage migration and Rollback procedure
to ignore any project-level validation error that can happen in a
long-running instance.
There are many situations where defaults and acceptable values changed
but, because we didn't provide a migration to "valid" attributes, it
can happen that project will not be `valid? => true`.
Because the changes we are making are limited to setting a project as
read_only or changing the storage_level, it's safe to bypass validation.
This change takes the case where repository doesn't exist on disk
and make it ignore but succeed the step, increasing or decreasing the
version depending on the operation.
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).
Cleanup code, and refactor tests that still use Rugged. After this, there should
be no Rugged code that access the instance's repositories on non-test
environments. There is still some rugged code for other tasks like the
repository import task, but since it doesn't access any repository storage path
it can stay.
Direct disk access is done through Gitaly now, so the legacy path was
deprecated. This path was used in Gitlab::Shell however. This required
the refactoring in this commit.
Added is the removal of direct path access on the project model, as that
lookup wasn't needed anymore is most cases.
Closes https://gitlab.com/gitlab-org/gitaly/issues/1111
GitLab Bot