diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-02 21:07:42 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-02 21:07:42 +0300 |
commit | 7b52c7cb634ef7047d30b0337fe477bcdcedf41d (patch) | |
tree | 374ca9e908204488422046f10e340d1500780362 /spec/workers | |
parent | b375c6c05fbd03aea33a9ee9f82e678bdaa8c3cc (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'spec/workers')
-rw-r--r-- | spec/workers/every_sidekiq_worker_spec.rb | 30 |
1 files changed, 15 insertions, 15 deletions
diff --git a/spec/workers/every_sidekiq_worker_spec.rb b/spec/workers/every_sidekiq_worker_spec.rb index f3ee1dc8435..d6e867ee407 100644 --- a/spec/workers/every_sidekiq_worker_spec.rb +++ b/spec/workers/every_sidekiq_worker_spec.rb @@ -71,30 +71,30 @@ describe 'Every Sidekiq worker' do # concurrency, so that each job can consume a large amounts of memory. For this reason, on # GitLab.com, when a large number of memory-bound jobs arrive at once, we let them queue up # rather than scaling the hardware to meet the SLO. For this reason, memory-bound, - # latency-sensitive jobs are explicitly discouraged and disabled. - it 'is (exclusively) memory-bound or latency-sentitive, not both', :aggregate_failures do - latency_sensitive_workers = workers_without_defaults - .select(&:latency_sensitive_worker?) + # high urgency jobs are explicitly discouraged and disabled. + it 'is (exclusively) memory-bound or high urgency, not both', :aggregate_failures do + high_urgency_workers = workers_without_defaults + .select { |worker| worker.get_urgency == :high } - latency_sensitive_workers.each do |worker| - expect(worker.get_worker_resource_boundary).not_to eq(:memory), "#{worker.inspect} cannot be both memory-bound and latency sensitive" + high_urgency_workers.each do |worker| + expect(worker.get_worker_resource_boundary).not_to eq(:memory), "#{worker.inspect} cannot be both memory-bound and high urgency" end end - # In high traffic installations, such as GitLab.com, `latency_sensitive` workers run in a - # dedicated fleet. In order to ensure short queue times, `latency_sensitive` jobs have strict + # In high traffic installations, such as GitLab.com, `urgency :high` workers run in a + # dedicated fleet. In order to ensure short queue times, `urgency :high` jobs have strict # SLOs in order to ensure throughput. However, when a worker depends on an external service, # such as a user's k8s cluster or a third-party internet service, we cannot guarantee latency, # and therefore throughput. An outage to an 3rd party service could therefore impact throughput - # on other latency_sensitive jobs, leading to degradation through the GitLab application. - # Please see doc/development/sidekiq_style_guide.md#Jobs-with-External-Dependencies for more + # on other high urgency jobs, leading to degradation through the GitLab application. + # Please see doc/development/sidekiq_style_guide.md#jobs-with-external-dependencies for more # details. - it 'has (exclusively) external dependencies or is latency-sentitive, not both', :aggregate_failures do - latency_sensitive_workers = workers_without_defaults - .select(&:latency_sensitive_worker?) + it 'has (exclusively) external dependencies or is high urgency, not both', :aggregate_failures do + high_urgency_workers = workers_without_defaults + .select { |worker| worker.get_urgency == :high } - latency_sensitive_workers.each do |worker| - expect(worker.worker_has_external_dependencies?).to be_falsey, "#{worker.inspect} cannot have both external dependencies and be latency sensitive" + high_urgency_workers.each do |worker| + expect(worker.worker_has_external_dependencies?).to be_falsey, "#{worker.inspect} cannot have both external dependencies and be high urgency" end end end |