feat: remove internal gitlab (#3297)

Co-authored-by: Rok Roškar <[email protected]>

CHANGELOG.rst

@@ -3,20 +3,31 @@
 0.62.0
 ------
 
+This release removes the Gitlab omnibus Helm chart that we created and used to have as a dependency
+of the Renku Helm chart. We have been discouraging anyone from using
+this chart in production and we specified this in our documentation as well.
+
+If you are using the internal Gitlab Helm chart then ensure to migrate to a separate
+Gitlab deployment as specified in our `documentation <https://renku.readthedocs.io/en/stable/how-to-guides/admin/gitlab.html#migrate-from-renku-bundled-omnibus-gitlab-to-cloud-native-gitlab-helm-chart>`_.
+before installing this or any subsequent Renku version. Gitlab publishes an official Helm chart and
+that is what should be used for deploying Gitlab with Helm.
+
 Internal Changes
 ~~~~~~~~~~~~~~~~
 
 **Improvements**
 
 * **Infrastructure Components**: ``redis`` has been upgraded from version ``7.0.7`` to ``7.4.1``
 
+* **Helm chart**: remove the custom-made Gitlab Omnibus Helm chart from Renku dependencies
+
 0.61.0
 ------
 
 Renku 0.61.0 introduces a new version of Amalthea that supports running sessions with Docker images
 that do not contain Jupyter server.
 
-NOTES to administrators: 
+NOTES to administrators:
 
 - This upgrade introduces a brand new CRD for sessions. All services that support
   sessions for Renku v2 will switch to this new CRD. Renku v1 sessions remain unchanged.
@@ -26,15 +37,15 @@ NOTES to administrators:
   notify users of the change and allow for enough time so that existing Renku v2 sessions can be saved and
   cleaned up, rather than asking users to save the url to their sessions. In addition to users not being able
   to see old Renku v2 sessions, they will also not be able to pause, resume or delete old Renku v2 sessions.
-  Therefore it's best if most sessions are properly saved and cleaned up before this update is rolled out. In order 
+  Therefore it's best if most sessions are properly saved and cleaned up before this update is rolled out. In order
   to support the new CRD we have also created a new operator that will manage the new `amaltheasession` resources.
 
-- The network policies for Renku have been consolidated and revamped. The most notable change here is the 
+- The network policies for Renku have been consolidated and revamped. The most notable change here is the
   removal of the egress policy that prevented egress to internal IP addresses from sessions. Now we disallow
   all ingress in the Renku release namespace by default and explicitly grant permissions to any pods that need
   to access other pods inside the Renku release namespace. Two properties relevant to this have been added to the
   Helm chart values file that allows administrators to grant access to all Renku services from a specific namespace
-  or to do the same for specific pods within the Renku namespace. These are not needed for Renku to function and the 
+  or to do the same for specific pods within the Renku namespace. These are not needed for Renku to function and the
   default network policies should be sufficient, they have been added so that administrators can allow ingress for
   other services that may not come with the Renku Helm chart such as logging or monitoring. This change will result in
   the removal of some network policies and the creation of several new policies.

docs/how-to-guides/admin/gitlab.rst

@@ -81,19 +81,8 @@ and existing GitLab users can use Renku without creating a separate Renku accoun
 GitLab deployed as part of Renku
 --------------------------------
 
-We do *not* recommend deploying the Renku-bundled GitLab as part of a production Renku deployment, 
-and instead suggest deploying GitLab using the `official GitLab cloud-native Kubernetes chart 
-<https://docs.gitlab.com/charts/>`_. Deploying GitLab as part of Renku may be deprecated in the future.
-
-If your Renku deployment includes GitLab you need to follow some additional steps to configure an admin user on GitLab.
-
-To grant a GitLab user the GitLab admin role without having access to the GitLab Web UI, the following steps can be taken in the GitLab container console.
-
-#. Run ``gitlab-rails console -e production`` (this might take a while).
-#. Find the user you would like to grant the admin role, for example by running ``user = User.find_by(email: '[email protected]')`` or ``user = User.find_by(username: 'renku')``.
-#. Grant the user the administrator role by running ``user.admin = true``.
-#. Save the user's profile by running ``user.save!``.
-#. Leave the console by running ``exit``.
+Deploying the GitLab Helm chart as part of the Renku Helm chart has been deprecated. If you have a Renku deployment that uses
+the Gitlab version that used to come bundled with Renku, then please follow the instructions below to migrate.
 
 Migrate from Renku-bundled Omnibus GitLab to cloud-native Gitlab Helm chart
 ---------------------------------------------------------------------------