Using consolidated configuration for object storage?

How to Use GitLab Self-managed
1

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 Content-MD5 headers.
    = 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.)

2

If you are already using consolidated form you have to configure the individual form for all components using object storage at once.
If you are not using object storage you can enable it and migrate for each component at a time, since it’s disabled by default.

Single vs. multiple credentials approach is really up to the requirements. If it will be stored in a single S3 storage I (personally) don’t see any benefits in having 8 accounts instead of 1.