Gitlab NFS deprecated support

I am using Gitlab Omnibus for 1k architecture. I am at 15.5.0 and I say a note in the removals for 15.6 that NFS is no longer supported. So I was using the NFS filesystem. But when I see the Gitaly configuration page it says it is preconfigured for 1k architecture. Does that mean I need not do any changes with respect to NFS moving to 15.6 or ahead. If Gitaly is preconfigured I see none of the fields marked in the gitlab.rb file with respect to Gitaly. So what do I do if Im using the 1k architecture, stay with NFS or move to the 2k architecture and configure Gitaly.

Hi,

NFS is deprecated, therefore, you have to move away from NFS - you cannot use it. The gitlab.rb file doesn’t get updated when you upgrade Gitlab. If no entries exist, then the defaults are applied. It’s the same as having an up-to-date file which has all the gitaly fields hashed out. As an example, here is everything related to Gitaly which is hashed out in newer installs of gitlab (or by looking at /opt/gitlab/etc/gitlab.rb.template once you’ve updated Gitlab).

### Gitaly settings
# gitlab_rails['gitaly_token'] = 'secret token'
## Gitaly
# The gitaly['enable'] option exists for the purpose of cluster
# deployments, see https://docs.gitlab.com/ee/administration/gitaly/index.html .
# gitaly['enable'] = true
# gitaly['dir'] = "/var/opt/gitlab/gitaly"
# gitaly['log_directory'] = "/var/log/gitlab/gitaly"
# gitaly['bin_path'] = "/opt/gitlab/embedded/bin/gitaly"
# gitaly['env_directory'] = "/opt/gitlab/etc/gitaly/env"
# gitaly['env'] = {
# gitaly['runtime_dir'] = "/var/opt/gitlab/gitaly/run"
# gitaly['socket_path'] = "/var/opt/gitlab/gitaly/gitaly.socket"
# gitaly['listen_addr'] = "localhost:8075"
# gitaly['tls_listen_addr'] = "localhost:9075"
# gitaly['certificate_path'] = "/var/opt/gitlab/gitaly/certificate.pem"
# gitaly['key_path'] = "/var/opt/gitlab/gitaly/key.pem"
# gitaly['prometheus_listen_addr'] = "localhost:9236"
# gitaly['logging_level'] = "warn"
# gitaly['logging_format'] = "json"
# gitaly['logging_sentry_dsn'] = "https://<key>:<secret>@sentry.io/<project>"
# gitaly['logging_ruby_sentry_dsn'] = "https://<key>:<secret>@sentry.io/<project>"
# gitaly['logging_sentry_environment'] = "production"
# gitaly['prometheus_grpc_latency_buckets'] = "[0.001, 0.005, 0.025, 0.1, 0.5, 1.0, 10.0, 30.0, 60.0, 300.0, 1500.0]"
# gitaly['auth_token'] = '<secret>'
# gitaly['auth_transitioning'] = false # When true, auth is logged to Prometheus but NOT enforced
# gitaly['graceful_restart_timeout'] = '1m' # Grace time for a gitaly process to finish ongoing requests
# gitaly['git_catfile_cache_size'] = 100 # Number of 'git cat-file' processes kept around for re-use
# gitaly['git_bin_path'] = "/opt/gitlab/embedded/bin/git" # A custom path for the 'git' executable
# gitaly['use_bundled_git'] = true # Whether to use bundled Git.
# gitaly['open_files_ulimit'] = 15000 # Maximum number of open files allowed for the gitaly process
# gitaly['ruby_max_rss'] = 300000000 # RSS threshold in bytes for triggering a gitaly-ruby restart
# gitaly['ruby_graceful_restart_timeout'] = '10m' # Grace time for a gitaly-ruby process to finish ongoing requests
# gitaly['ruby_restart_delay'] = '5m' # Period of sustained high RSS that needs to be observed before restarting gitaly-ruby
# gitaly['ruby_num_workers'] = 3 # Number of gitaly-ruby worker processes. Minimum 2, default 2.
# gitaly['concurrency'] = [
#     'rpc' => "/gitaly.SmartHTTPService/PostReceivePack",
#     'rpc' => "/gitaly.SSHService/SSHUploadPack",
# gitaly['rate_limiting'] = [
#     'rpc' => "/gitaly.SmartHTTPService/PostReceivePack",
#     'rpc' => "/gitaly.SSHService/SSHUploadPack",
# gitaly['daily_maintenance_start_hour'] = 22
# gitaly['daily_maintenance_start_minute'] = 30
# gitaly['daily_maintenance_duration'] = '30m'
# gitaly['daily_maintenance_storages'] = ["default"]
# gitaly['daily_maintenance_disabled'] = false
# gitaly['cgroups_mountpoint'] = '/sys/fs/cgroup'
# gitaly['cgroups_hierarchy_root'] = 'gitaly'
# gitaly['cgroups_memory_bytes'] = 1048576
# gitaly['cgroups_cpu_shares'] = 512
# gitaly['cgroups_repositories_count'] = 1000
# gitaly['cgroups_repositories_memory_bytes'] = 12884901888
# gitaly['cgroups_repositories_cpu_shares'] = 128
# gitaly['pack_objects_cache_enabled'] = true
# gitaly['pack_objects_cache_dir'] = '/var/opt/gitlab/git-data/repositories/+gitaly/PackObjectsCache'
# gitaly['pack_objects_cache_max_age'] = '5m'
# gitaly['custom_hooks_dir'] = "/var/opt/gitlab/gitaly/custom_hooks"
##! Service name used to register Gitaly as a Consul service
# gitaly['consul_service_name'] = 'gitaly'
##! Semantic metadata used when registering Gitaly as a Consul service
# gitaly['consul_service_meta'] = {}
##! Docs: https://gitlab.com/gitlab-org/gitaly/blob/master/doc/design_ha.md
#  'GITALY_PID_FILE' => "/var/opt/gitlab/praefect/praefect.pid",
# praefect['wrapper_path'] = "/opt/gitlab/embedded/bin/gitaly-wrapper"

so since your `gitlab.rb``` doesn’t have any entries, it’s the same as what is commented out above. Which means your install will be using Gitaly with those values.

1 Like

But we are using 1k Architecture so in the document says Gitaly is preconfigured and they have given these configuration steps in 2k architecture . So should we move to 2k architecture or how do I move away from NFS in 1k architecture.

It doesn’t matter what you are using, NFS is deprecated. Whether it is up to 500 or 1000 users, it’s still using Gitaly underneath for newer versions. If you are using 2K, then you probably need to configure Gitaly so that it’s performance is better which is why the documentation suggests configuring specific Gitaly options. Otherwise, for 500 or 1K users, the defaults are most likely to be fine.

Obviously make backups before you attempt anything.

See: Deprecations by version | GitLab
And: Gitaly and Gitaly Cluster | GitLab

The last link explains migrating to Gitaly.

1 Like

So if Im using 1k the code gets migrated automatically to Gitaly?? and also they say that Gitaly is preconfigured in 1k but I dont see everything is hashed in the gitlab.rb in gitaly section

As I said, you may have an old gitlab.rb which doesn’t have gitaly entries. As I explained, if there are no entries for it, hashed or not, it will use the default values that I posted in what was actually hashed out in the gitlab.rb template file.

1 Like

So as part of 1k architecture upgrade to 15.8 how do I move away from NFS?

I suggest reading the documentation that I linked. I don’t use NFS, so you’ll have to follow the migrate to gitaly link that I posted. Pretty much everything you can do with Gitlab is in the documentation.

Either that or wait for someone from the community who might have done such migration - maybe they will offer some ideas…

1 Like