recommends using the so called “consolidated form” where
A single credential is shared by all supported object types
that sounds bad, and we’re actually considering making multiple accounts on our (S3 compatible) storage system for different use cases, a natural consequence will be that those get different access credentials, necessitating a switch to the old storage-specific form.
Is there any (good) reasons not to do that? I do realise that we won’t get any of the listed benefits from using the consolidated form:
- It can simplify your GitLab configuration since the connection details are shared across object types.
= What we want to achieve is not really compatible with a simple configuration, and it’s in our configuration management anyway
- It enables the use of encrypted S3 buckets.
= I don’t think we need that.
- It uploads files to S3 with proper
= I haven’t read the entire issue that is linked to, but can’t see why a simple matter of configuration affects how multi-part uploads work; but we can probably live with that.
But will the storage-specific form stay in GitLab? The documentation only describes how to transition to the consolidated form, not the other way.
On that in the section on Transition to consolidated form it says
The consolidated form is used only if all lines from the original form is omitted.
Does that imply that as soon as I start to configure anything (that supports consolidated configuration) to use storage-specific configuration, I have to do that configuration for every type of object? It doesn’t seem to matter that we have both the consolidated configuration and storage-specific configuration for registries. (Getting everything configured in a unified way looks like a good thing.)