Workhorse configuration discrepency

When migrating over the API fleet, workhorse maintained the same configuration that was created with the git fleet was migrated over. This was done via: gitlab-com/gl-infra/k8s-workloads/gitlab-com!459 (merged)

Currently we are unable to segregate out the values per webservice deployment, so any change to .workhorse.extraArgs will impact all webservice deployments. Tracking issue for this is here: gitlab-org/charts/gitlab#2365 (closed)

They've been bumped over time, and each fleet was bumped independently.

They all started off at a value of 100: https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/608

And was later bumped to 200: https://ops.gitlab.net/gitlab-cookbooks/chef-repo/-/commit/66e1ad5d4797d272be3e924519cfbb73bc672582

And lastly we somehow settled on 2000 for the API fleet: https://ops.gitlab.net/gitlab-cookbooks/chef-repo/-/commit/a393628b7f0fbcd821980051eda0a03f9bd9aeb1

I'm lacking historical context on each time this occurs due to how old these are and no ties into merge requests or issues.

---

• Can we safely bump these values to the same without negatively impacting the git webservice deployment?

-apiLimit 9 -apiQueueDuration 30s -apiQueueLimit 2000

vs the current 

-apiLimit 5 -apiQueueDuration 60s -apiQueueLimit 200

Solution

After testing we are indeed able to take workhorse configurations separately just fine. This can be seen in the following MR: gitlab-com/gl-infra/k8s-workloads/gitlab-com!869 (merged)