|
2 | 2 | stage: Systems |
3 | 3 | group: Distribution |
4 | 4 | info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments |
| 5 | +remove_date: '2024-08-21' |
| 6 | +redirect_to: 'https://docs.gitlab.com/ee/update/package/index.html#version-specific-changes' |
5 | 7 | --- |
6 | 8 |
|
7 | | -# GitLab 14 specific changes **(FREE SELF)** |
| 9 | +This document was moved to [another location](https://docs.gitlab.com/ee/update/package/index.html#version-specific-changes). |
8 | 10 |
|
9 | | -NOTE: |
10 | | -When upgrading to a new major version, remember to first [check for background migrations](https://docs.gitlab.com/ee/update/index.html#checking-for-background-migrations-before-upgrading). |
11 | | - |
12 | | -## 14.10 |
13 | | - |
14 | | -### Gitaly runtime directory |
15 | | - |
16 | | -In 14.10, Gitaly has introduced a new runtime directory. This directory is |
17 | | -intended to hold all files and directories Gitaly needs to create at runtime in |
18 | | -order to operate correctly. This includes for example internal sockets, the Git |
19 | | -execution environment or the temporary hooks directory. |
20 | | - |
21 | | -This new configuration can be set via `gitaly['runtime_dir']`. It replaces the |
22 | | -the old `gitaly['internal_socket_dir']` configuration: if the internal socket |
23 | | -directory is not explicitly configured, sockets will be created in the runtime |
24 | | -directory. |
25 | | - |
26 | | -Support for `gitaly['internal_socket_dir']` will be removed in 15.0. |
27 | | - |
28 | | -## 14.7 |
29 | | - |
30 | | -### Redis 6.2.6 |
31 | | - |
32 | | -In 14.8, we are upgrading Redis from 6.0.16 to 6.2.6. This upgrade is expected |
33 | | -to be fully backwards compatible. |
34 | | - |
35 | | -If your instance has Redis HA with Sentinel, follow the upgrade steps documented in |
36 | | -[Update GitLab installed with the Linux package](https://docs.gitlab.com/ee/update/zero_downtime.html#redis-ha-using-sentinel) |
37 | | - |
38 | | -## 14.4 |
39 | | - |
40 | | -### Downgrading Grafana from 8.1 to 7.5 |
41 | | - |
42 | | -In GitLab 14.4 the provided Grafana version is 7.5, this is a downgrade from |
43 | | -the Grafana 8.1 version introduced in GitLab 14.3. This was reverted to an |
44 | | -Apache-licensed Grafana release to allow time to consider the implications of |
45 | | -the newer AGPL-licensed releases. |
46 | | - |
47 | | -Users that have customized their Grafana install with plugins or library |
48 | | -panels may experience errors in Grafana after the downgrade. If the errors |
49 | | -persist after a Grafana restart you may need to reset the Grafana db and |
50 | | -re-add the customizations. The Grafana database can be reset with |
51 | | -`sudo gitlab-ctl reset-grafana`. |
52 | | - |
53 | | -## 14.0 |
54 | | - |
55 | | -### Removing support for running Sidekiq directly instead of `sidekiq-cluster` |
56 | | - |
57 | | -In GitLab 13.0, `sidekiq-cluster` was enabled by default and the `sidekiq` |
58 | | -service ran `sidekiq-cluster` under the hood. However, users could control this |
59 | | -behavior using `sidekiq['cluster']` setting to run Sidekiq directly instead. |
60 | | -Users could also run `sidekiq-cluster` separately using the various |
61 | | -`sidekiq_cluster[*]` settings available in `gitlab.rb`. However these features |
62 | | -were deprecated and are now being removed. |
63 | | - |
64 | | -Starting with GitLab 14.0, `sidekiq-cluster` becomes the only way to run Sidekiq |
65 | | -in `omnibus-gitlab` installations. As part of this process, support for the |
66 | | -following settings in `gitlab.rb` is being removed: |
67 | | - |
68 | | -1. `sidekiq['cluster']` setting. Sidekiq can only be run using `sidekiq-cluster` |
69 | | - now. |
70 | | - |
71 | | -1. `sidekiq_cluster[*]` settings. They should be set via respective `sidekiq[*]` |
72 | | - counterparts. |
73 | | - |
74 | | -1. `sidekiq['concurrency']` setting. The limits should be controlled using the |
75 | | - two settings `sidekiq['min_concurrency']` and `sidekiq['max_concurrency']`. |
76 | | - |
77 | | -### Removing support for using Unicorn as web server |
78 | | - |
79 | | -In GitLab 13.0, Puma became the default web server for GitLab, but users were |
80 | | -still able to continue using Unicorn if needed. Starting with GitLab 14.0, |
81 | | -Unicorn is no longer supported as a webserver for GitLab and is no longer |
82 | | -shipped with the `omnibus-gitlab` packages. Users must migrate to Puma following |
83 | | -[documentation](https://docs.gitlab.com/ee/administration/operations/puma.html) |
84 | | -to upgrade to GitLab 14.0. |
85 | | - |
86 | | -### Consul upgrade |
87 | | - |
88 | | -The Consul version has been updated from `1.6.10` to `1.9.6` for Geo and multi-node PostgreSQL installs. Its important |
89 | | -that Consul nodes be upgraded and restarted one at a time. |
90 | | - |
91 | | -See our [Consul upgrade instructions](https://docs.gitlab.com/ee/administration/consul.html#upgrade-the-consul-nodes). |
92 | | - |
93 | | -### Automatically generating an initial root password |
94 | | - |
95 | | -Starting with GitLab 14.0, GitLab automatically generates a password for initial |
96 | | -administrator user (`root`) and stores this value to |
97 | | -`/etc/gitlab/initial_root_password`. For details, see the |
98 | | -[documentation on initial login](../installation/index.md#set-up-the-initial-password). |
99 | | - |
100 | | -### PostgreSQL 11 and repmgr removal |
101 | | - |
102 | | -The binaries for PostgreSQL 11 and repmgr have been removed. |
103 | | - |
104 | | -Prior to upgrading, administrators of Linux package installations must: |
105 | | - |
106 | | -1. Ensure the installation is using [PostgreSQL 12](../settings/database.md#upgrade-packaged-postgresql-server) |
107 | | -1. If using repmgr, [convert to using patroni](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#switching-from-repmgr-to-patroni) |
108 | | - |
109 | | -### Redis configuration changes |
110 | | - |
111 | | -Two configuration options for Redis were deprecated in GitLab 13 and removed in GitLab 14: |
112 | | - |
113 | | -- `redis_slave_role` is replaced with `redis_replica_role` |
114 | | -- `redis['client_output_buffer_limit_slave']` is replaced with `redis['client_output_buffer_limit_replica']` |
115 | | - |
116 | | -Redis Cache nodes being upgraded from GitLab 13.12 to 14.0 that still refer to `redis_slave_role` |
117 | | -in `gitlab.rb` will encounter an error in the output of `gitlab-ctl reconfigure`: |
118 | | - |
119 | | -```plaintext |
120 | | -There was an error running gitlab-ctl reconfigure: |
121 | | -
|
122 | | -The following invalid roles have been set in 'roles': redis_slave_role |
123 | | -``` |
| 11 | +<!-- This redirect file can be deleted after 2024-08-21. --> |
| 12 | +<!-- Redirects that point to other docs in the same project expire in three months. --> |
| 13 | +<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. --> |
| 14 | +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html --> |
0 commit comments