Merge branch '330402-remove-unicorn-gitlab-comments' into 'master'

Remove Unicorn support: comments

See merge request gitlab-org/gitlab!62010

app/models/concerns/prometheus_adapter.rb

@@ -38,7 +38,7 @@ module PrometheusAdapter
 
     # This is a heavy-weight check if a prometheus is properly configured and accessible from GitLab.
     # This actually sends a request to an external service and often it could take a long time,
-    # Please consider using `configured?` instead if the process is running on unicorn/puma threads.
+    # Please consider using `configured?` instead if the process is running on Puma threads.
     def can_query?
       prometheus_client.present?
     end

config/initializers/macos.rb

@@ -5,7 +5,7 @@ if /darwin/ =~ RUBY_PLATFORM
     require 'fiddle'
 
     # Dynamically load Foundation.framework, ~implicitly~ initialising
-    # the Objective-C runtime before any forking happens in Unicorn
+    # the Objective-C runtime before any forking happens in webserver
     #
     # From https://bugs.ruby-lang.org/issues/14009
     Fiddle.dlopen '/System/Library/Frameworks/Foundation.framework/Foundation'

config/initializers/rack_timeout.rb

 # frozen_string_literal: true
 
-# Unicorn terminates any request which runs longer than 60 seconds.
 # Puma doesn't have any timeout mechanism for terminating long-running
 # requests, to make sure that server is not paralyzed by long-running
 # or stuck queries, we add a request timeout which terminates the

config/initializers/tracing.rb

@@ -15,7 +15,7 @@ if Labkit::Tracing.enabled?
   Labkit::Tracing::Rails::ActionViewSubscriber.instrument
   Labkit::Tracing::Rails::ActiveSupportSubscriber.instrument
 
-  # In multi-processed clustered architectures (puma, unicorn) don't
+  # In multi-processed clustered architectures (e.g. Puma cluster) don't
   # start tracing until the worker processes are spawned. This works
   # around issues when the opentracing implementation spawns threads
   Gitlab::Cluster::LifecycleEvents.on_worker_start do

lib/gitlab/cluster/lifecycle_events.rb

@@ -8,13 +8,13 @@ module Gitlab
     # LifecycleEvents lets Rails initializers register application startup hooks
     # that are sensitive to forking. For example, to defer the creation of
     # watchdog threads. This lets us abstract away the Unix process
-    # lifecycles of Unicorn, Sidekiq, Puma, Puma Cluster, etc.
+    # lifecycles of Sidekiq, Puma, Puma Cluster, etc.
     #
     # We have the following lifecycle events.
     #
     # - on_before_fork (on master process):
     #
-    #     Unicorn/Puma Cluster: This will be called exactly once,
+    #     Puma Cluster: This will be called exactly once,
     #       on startup, before the workers are forked. This is
     #       called in the PARENT/MASTER process.
     #
@@ -22,7 +22,7 @@ module Gitlab
     #
     # - on_master_start (on master process):
     #
-    #     Unicorn/Puma Cluster: This will be called exactly once,
+    #     Puma Cluster: This will be called exactly once,
     #       on startup, before the workers are forked. This is
     #       called in the PARENT/MASTER process.
     #
@@ -30,7 +30,7 @@ module Gitlab
     #
     # - on_before_blackout_period (on master process):
     #
-    #     Unicorn/Puma Cluster: This will be called before a blackout
+    #     Puma Cluster: This will be called before a blackout
     #       period when performing graceful shutdown of master.
     #       This is called on `master` process.
     #
@@ -38,7 +38,7 @@ module Gitlab
     #
     # - on_before_graceful_shutdown (on master process):
     #
-    #     Unicorn/Puma Cluster: This will be called before a graceful
+    #     Puma Cluster: This will be called before a graceful
     #       shutdown  of workers starts happening, but after blackout period.
     #       This is called on `master` process.
     #
@@ -46,11 +46,6 @@ module Gitlab
     #
     # - on_before_master_restart (on master process):
     #
-    #     Unicorn: This will be called before a new master is spun up.
-    #       This is called on forked master before `execve` to become
-    #       a new masterfor Unicorn. This means that this does not really
-    #       affect old master process.
-    #
     #     Puma Cluster: This will be called before a new master is spun up.
     #       This is called on `master` process.
     #
@@ -58,7 +53,7 @@ module Gitlab
     #
     # - on_worker_start (on worker process):
     #
-    #     Unicorn/Puma Cluster: This is called in the worker process
+    #     Puma Cluster: This is called in the worker process
     #       exactly once before processing requests.
     #
     #     Sidekiq/Puma Single: This is called immediately.
@@ -114,7 +109,7 @@ module Gitlab
         end
 
         #
-        # Lifecycle integration methods (called from unicorn.rb, puma.rb, etc.)
+        # Lifecycle integration methods (called from puma.rb, etc.)
         #
         def do_worker_start
           call(:worker_start_hooks, @worker_start_hooks)

lib/gitlab/cluster/puma_worker_killer_initializer.rb

@@ -12,12 +12,9 @@ module Gitlab
         require 'puma_worker_killer'
 
         PumaWorkerKiller.config do |config|
-          # Note! ram is expressed in megabytes (whereas GITLAB_UNICORN_MEMORY_MAX is in bytes)
-          # Importantly RAM is for _all_workers (ie, the cluster),
-          # not each worker as is the case with GITLAB_UNICORN_MEMORY_MAX
           worker_count = puma_options[:workers] || 1
-          # The Puma Worker Killer checks the total RAM used by both the master
-          # and worker processes.
+          # The Puma Worker Killer checks the total memory used by the cluster,
+          # i.e. both primary and worker processes.
           # https://github.com/schneems/puma_worker_killer/blob/v0.1.0/lib/puma_worker_killer/puma_memory.rb#L57
           #
           # Additional memory is added when running in `development`

lib/gitlab/stack_prof.rb

@@ -118,7 +118,6 @@ module Gitlab
       #
       # see also:
       # * https://github.com/puma/puma/blob/master/docs/signals.md#puma-signals
-      # * https://github.com/phusion/unicorn/blob/master/SIGNALS
       # * https://github.com/mperham/sidekiq/wiki/Signals
       Signal.trap('SIGUSR2') do
         write.write('.')

lib/support/init.d/gitlab.default.example

@@ -5,9 +5,6 @@
 # Normal values are "production", "test" and "development".
 RAILS_ENV="production"
 
-# Uncomment the line below to enable the Unicorn web server instead of Puma.
-# use_web_server="unicorn"
-
 # app_user defines the user that GitLab is run as.
 # The default is "git".
 app_user="git"
@@ -43,7 +40,7 @@ gitlab_workhorse_pid_path="$pid_path/gitlab-workhorse.pid"
 # socket. To listen on TCP connections (needed by Apache) change to:
 # '-listenNetwork tcp -listenAddr 127.0.0.1:8181'
 #
-# The -authBackend setting tells gitlab-workhorse where it can reach Unicorn.
+# The -authBackend setting tells gitlab-workhorse where it can reach the GitLab Rails application.
 # For relative URL support change to:
 # '-authBackend http://127.0.0.1/8080/gitlab'
 # Read more in http://doc.gitlab.com/ce/install/relative_url.html

lib/tasks/gitlab/setup.rake

@@ -40,7 +40,7 @@ namespace :gitlab do
   end
 
   # If there are any clients connected to the DB, PostgreSQL won't let
-  # you drop the database. It's possible that Sidekiq, Unicorn, or
+  # you drop the database. It's possible that Sidekiq, Puma, or
   # some other client will be hanging onto a connection, preventing
   # the DROP DATABASE from working. To workaround this problem, this
   # method terminates all the connections so that a subsequent DROP

workhorse/internal/api/api.go

@@ -308,7 +308,7 @@ func (api *API) PreAuthorizeHandler(next HandleFunc, suffix string) http.Handler
 			return
 		}
 
-		httpResponse.Body.Close() // Free up the Unicorn worker
+		httpResponse.Body.Close() // Free up the Puma thread
 
 		copyAuthHeader(httpResponse, w)
 
@@ -347,7 +347,7 @@ func copyAuthHeader(httpResponse *http.Response, w http.ResponseWriter) {
 
 func passResponseBack(httpResponse *http.Response, w http.ResponseWriter, r *http.Request) {
 	// NGINX response buffering is disabled on this path (with
-	// X-Accel-Buffering: no) but we still want to free up the Unicorn worker
+	// X-Accel-Buffering: no) but we still want to free up the Puma thread
 	// that generated httpResponse as fast as possible. To do this we buffer
 	// the entire response body in memory before sending it on.
 	responseBody, err := bufferResponse(httpResponse.Body)
@@ -355,7 +355,7 @@ func passResponseBack(httpResponse *http.Response, w http.ResponseWriter, r *htt
 		helper.Fail500(w, r, err)
 		return
 	}
-	httpResponse.Body.Close() // Free up the Unicorn worker
+	httpResponse.Body.Close() // Free up the Puma thread
 	bytesTotal.Add(float64(responseBody.Len()))
 
 	for k, v := range httpResponse.Header {