Improve new storage layer
There are a few remaining things to address from !2477 (merged) discussion listed below:
-
@brodock started a discussion: (+1 comment) I'm almost convinced we can change this to
disk_path
(in order to use the future UUID), so cache should not be cleared anymore while moving or renaming. Any possible side-effects ? (do we store anything pointing to an URL?) -
@brodock started a discussion: I don't understand the context for this one, so we probably need to provide a fallback support here.
-
@brodock started a discussion: This is in a concern already so we either change the load order of the Storage concerns and skip when not
defined?
or add a check here in the future to skip like when notGitlab::Storage.legacy?
-
@brodock started a discussion: We should add a check here in the future to skip when not `Gitlab::Storage.legacy?
-
@brodock started a discussion: We should add a check here in the future to skip when not `Gitlab::Storage.legacy?
-
@brodock started a discussion: We need to decide if we should also store the uploads in an UUID path or not. I think it makes sense to go all UUID for everything related
-
@smcgivern started a discussion: (+3 comments) @brodock I'd like to bikeshed a little:
We want that any place in code that needs the routing URL uses
full_path
and any place that needs the path in disk usesdisk_path
. In this first iteration they may work similar but as soon as the new Storage Format comes to play the output will be very different.I don't like
full_path
. It's not a full path in filesystem terms (and that's meaningless with Gitaly anyway). How aboutuser_path
?
We also should fight the technical debit around upload folder:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13246#note_37257177 (we should use immutable paths there as well)