Clarify if we really need to migrate `gitlab-shell` `secret_token` when migrating to Omnibus from source

Migration from Source installation to Omnibus currently has a requirement to migrate gitlab-shell secret_token from source to Omnibus according to this documentation: https://docs.gitlab.com/omnibus/update/convert_to_omnibus.html

However, after testing it, it doesn't seem like it is required to copy it from source. We can succesfully push/pull on the Omnibus instance even without bringing the secret from source install.

As long as the secret is the same in the following files, the migrated Omnibus installation is working (we can pull/push from/to it):

• /etc/gitlab/gitlab-secrets.json
• /var/opt/gitlab/gitlab-rails/etc/gitlab_shell_secret (get populated from /etc/gitlab/gitlab-secrets.json)
• /opt/gitlab/embedded/service/gitlab-rails/.gitlab_shell_secret (symlink to /var/opt/gitlab/gitlab-rails/etc/gitlab_shell_secret) - used by Rails application to validate the requests coming from GitLab Shell or Gitaly to the internal API
• /opt/gitlab/embedded/service/gitlab-shell/.gitlab_shell_secret (symlink to /opt/gitlab/embedded/service/gitlab-rails/.gitlab_shell_secret) - used by GitLab Shell and Gitaly to authenticate with the GitLab internal API

Why do we actually need to migrate the secret from source if everything seems to work with the secret that we already have generated after the first reconfigure?

Is having the same secret accross all these files enough for a migration to be successful?

• Slack discussion: https://gitlab.slack.com/archives/C1FCTU4BE/p1634027943172000 [internal only]
• Customer ticket: https://gitlab.zendesk.com/agent/tickets/241785 [internal]

changed the description

added customer label

added devopssystems groupdistribution labels

added sectioncore platform label

changed the description

@twk3 @WarheadsSE I don't think there is a specific reason we need to have the same exact Shell secret to be replicated - that secret is not stored in any DB, and is only referenced from the specified files as mentioned in the description. And in the current state, modifying the shell secret will end up causing problems for users unless they restart gitaly due to gitaly#3837.

The secret's content needs to be stable at the time of services start, for all services that make use of it. However, there is no specific requirement to "bring it" from source, as the Omnibus will generate it when not specifically provided. This works find in smaller instances.

In larger instances, it may be "simpler" to express that this should be provided to all nodes with the associated roles, as a replacement to having to copy that particular portion of the gitlab-secrets.json around after one of the nodes generates it.

Agreed, the requirement is only that they are the same.

Though in a multi-node setup, where you are updating one node at a time from source to omnibus, its likely still best to re-use the contents of the existing secrets.

Fair enough.

@twk3 In that case, I think adding a gitaly restart/reload when contents of the shell secret change is worth it, while we wait to get a proper solution for gitaly#3837

mentioned in merge request !5669 (merged)

changed the description

added For Scheduling documentation up-for-grabs labels

mentioned in issue gitlab-org/distribution/team-tasks#938 (closed)

added group::distributiondeploy label

added groupself managed label and removed groupdistribution group::distributiondeploy [deprecated] labels