Consolidated object storage - bucket name required even if selected object storage disabled

Summary

If a user enables consolidated object storage https://docs.gitlab.com/ee/administration/object_storage.html#consolidated-object-storage-configuration, by default this enables object storage for all object types.

If a user then selectively disables some object storage types, they are still required to set a bucket name for that object type.

Our documentation does mention if you selectively disable object storage, then you still must specify a bucket name https://docs.gitlab.com/ee/administration/object_storage.html#selectively-disabling-object-storage, otherwise the reconfigure will fail. This seems very strange to me, why should the user specify a bucket name if they aren't using object storage?

Steps to reproduce

  1. Enable consolidated object storage https://docs.gitlab.com/ee/administration/object_storage.html#consolidated-object-storage-configuration

  2. Configure the artifacts object storage with the below:

    # Selectively disable artifacts object storage
    gitlab_rails['object_store']['objects']['artifacts']['enabled'] = false
    
    # Don't specify a bucket name for artifacts
    # gitlab_rails['object_store']['objects']['artifacts']['bucket'] = 'antons-artifacts-object-store'
    
    # Enable artifacts
    gitlab_rails['artifacts_enabled'] = true
  3. Reconfigure GitLab and you see this error:

    Running handlers:
    There was an error running gitlab-ctl reconfigure:
    
    execute[clear the gitlab-rails cache] (gitlab::gitlab-rails line 426) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
    ---- Begin output of /opt/gitlab/bin/gitlab-rake cache:clear ----
    STDOUT:
    STDERR: rake aborted!
    Object storage for artifacts must have a bucket specified
    /opt/gitlab/embedded/service/gitlab-rails/config/object_store_settings.rb:108:in `block in parse!'
    /opt/gitlab/embedded/service/gitlab-rails/config/object_store_settings.rb:101:in `each'
    /opt/gitlab/embedded/service/gitlab-rails/config/object_store_settings.rb:101:in `parse!'
    /opt/gitlab/embedded/service/gitlab-rails/config/initializers/1_settings.rb:618:in `<top (required)>'
    /opt/gitlab/embedded/service/gitlab-rails/config/environment.rb:5:in `<top (required)>'
    /opt/gitlab/embedded/bin/bundle:23:in `load'
    /opt/gitlab/embedded/bin/bundle:23:in `<main>'
    Tasks: TOP => cache:clear => cache:clear:redis => environment
    (See full trace by running task with --trace)
    ---- End output of /opt/gitlab/bin/gitlab-rake cache:clear ----
    Ran /opt/gitlab/bin/gitlab-rake cache:clear returned 1

Workaround

As per the documentation https://docs.gitlab.com/ee/administration/object_storage.html#selectively-disabling-object-storage, either specify a bucket name or disable the object type.

Example Project

(If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report)

(If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version)

What is the current bug behavior?

When selectively disabling object storage types with consolidated object storage, the user is forced to set a bucket name.

What is the expected correct behavior?

When selectively disabling object storage types with consolidated object storage, the user should not need to specify a bucket name.

Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise.)

Output of checks

(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:check SANITIZE=true)

(For installations from source run and paste the output of: sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)

(we will only investigate if the tests are passing)

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)