giseldo/neodataset huggingface dataset:
503 errors when using the Web Editor on staging

This could be related to 11.5.0 RC1, but we're not sure yet. To reproduce:

1. Find a repo on staging.gitlab.com
2. Click on the README.md or some file in the repository view
3. Click "Edit File"

I get 503s all the time.

The `production_json.log` shows:

```json
{"method":"PUT","path":"/stanhu/rouge-test/update/master/LICENSE","format":"html","controller":"Projects::BlobController","action":"update","status":503,"duration":55312.19,"view":17.46,"db":17.38,"time":"2018-11-06T17:32:36.571Z","params":[{"key":"utf8","value":"‚úì"},{"key":"_method","value":"put"},{"key":"authenticity_token","value":"[FILTERED]"},{"key":"file_path","value":"LICENSE"},{"key":"encoding","value":"text"},{"key":"commit_message","value":"Update LICENSE"},{"key":"branch_name","value":"master"},{"key":"original_branch","value":"master"},{"key":"last_commit_sha","value":"88d77e88631d11244bc105714eb2d15e4fd20a8b"},{"key":"content","value":"[FILTERED]"},{"key":"from_merge_request_iid","value":""},{"key":"namespace_id","value":"stanhu"},{"key":"project_id","value":"rouge-test"},{"key":"id","value":"master/LICENSE"}],"remote_ip":"64.71.20.74","user_id":64248,"username":"stanhu","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36","gitaly_calls":7}
```

Workhorse log shows:

```json
{"correlation-id":"lxcwkZTK0V7","duration":55.355355981,"host":"staging.gitlab.com","level":"info","method":"POST","msg":"access","proto":"HTTP/1.1","referer":"https://staging.gitlab.com/stanhu/rouge-test/edit/master/LICENSE","remoteAddr":"@","status":503,"system":"http","time":"2018-11-06T17:33:31Z","uri":"/stanhu/rouge-test/update/master/LICENSE","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36","written":2930}
```

Story points: 1.0
Test plan for testing Patroni replication environment

Test with QA the Patroni environment with QA.Infrastructure team has already done sync/replication testing. Quality team to help with functional tests.

* See that a Project with CI/CD is working
* MR is working
* Diff is displaying correctly
* Performance tests, we have some already in-flight automation by @at.ramya
* Load testing, use https://gitlab.com/gitlab-com/large-staging-collider that we used in GCP migration.

Follow-ups after the meeting

* @ahmadsherif will update the issue with env details.
* Quality team will work on turning this issue into a test plan.

**Recording:** https://drive.google.com/drive/folders/1KIf4mJsL6TABOizYDlyx_gfG84kblN8x

## Plan

* Run existing automated tests against the new environment
* Run our new performance test automation
* Run load tests using https://gitlab.com/gitlab-com/large-staging-collider

Story points: 5.0
Plan Monitoring/Visibility for Geo

Create a list of issues to validate that we are properly monitoring and alerting on the Geo infrastructure

Consider the following
- [ ] Ensure that our existing monitoring solution is sufficient:
- [ ] Ensure firewall rules are in place such that we can properly scrape for metrics:
- [x] Ensure that logging is in place: https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/6330
- [ ] Ensure that alerting  is routed properly for Geo:
- [x] Ensure Sentry is correctly configured for Geo: https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/6365

This issue can be closed when the above issues have been created.

Story points: 1.0
Discover recommended installation parameters for Geo

Gather a list of the following:
* ~~Where to build Geo (conversation started here: https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/4741 & https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5466#note_120537201)~~
* Instance sizing requirements
* Disk type requirements

This issue is only for discussion and discovery only.

Keep in mind the following when working on this issue:
* We only plan to sync repo and database data
* The region that we are placing this stuff in will not see customer traffic
* Consider places where we can reduce cost by using less expensive infrastructure components

Story points: 1.0
Discover current Geo implementation

Despite Geo currently being disabled for GitLab.com, we still have at least one server up and running and some configuration related to it.

Figure out what servers are around for Geo _currently_.  Compile a list of action items to tear those down.  Anything left right now would have been for the purpose of migrating to GCP, and since, they've been neglected.

This issue can be closed when issues from the above have been created.

Story points: 1.0
Introducing a small amount of traffic on staging cripples the environment

A small amount of load to the staging environment
* web: 22 req/sec
* api: ~100 req/sec
* git: ~100 req/sec

Starts to add enough load to cause problems.

https://dashboards.gitlab.net/d/RZmbBr7mk/gitlab-triage?orgId=1&var-environment=gstg&var-prometheus=prometheus-01-inf-gstg&var-prometheus_app=prometheus-app-01-inf-gstg&var-backend=All&var-type=All&var-stage=main&from=1541440657228&to=1541441618961


api/git/gitaly in particular:

![Screen_Shot_2018-11-05_at_7.25.15_PM](/uploads/4d8bc9dfef0b6558f824395b8c769aa8/Screen_Shot_2018-11-05_at_7.25.15_PM.png)
![Screen_Shot_2018-11-05_at_7.25.11_PM](/uploads/049aa7e4cd42e9d67ab73efe6b93e1d0/Screen_Shot_2018-11-05_at_7.25.11_PM.png)
![Screen_Shot_2018-11-05_at_7.25.05_PM](/uploads/f99a4e73b6005724f6c3844d2d0c4298/Screen_Shot_2018-11-05_at_7.25.05_PM.png)
![Screen_Shot_2018-11-05_at_7.24.59_PM](/uploads/2c956ffc0ba31156d11577ff94eb4b7b/Screen_Shot_2018-11-05_at_7.24.59_PM.png)

Story points: 2.0
Database Reviews

Last milestone: https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5335#

* [x] https://gitlab.com/gitlab-org/gitlab-ce/issues/52271#note_109523119 along with https://gitlab.com/gitlab-org/gitlab-ce/issues/49651#note_111247684
* [x] Sean https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/7903
* [x] Douwe https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22799
* [x] https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8231
* [x] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22808
* [x] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22433
* [x] https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8107
* [x] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22750/diffs#note_114883642
* [x] https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6947#note_114740347
* [x] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22522#note_115135349
* [x] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22308/diffs#note_115063771
* [x] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22799
* [ ] Recursive CTE https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22308#note_115367888
* [x] Sean https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21492#note_115661498 https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/7222#note_115909424
* [x] Douwe https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8120#note_116819401
* [x] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23020/diffs
* [x] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22694 and https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8232
* [ ] Sean https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8070
* [x] https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8120

Story points: 5.0
Research Improvements to the Docker Registry Monitoring/Alerting

Logging from our registry is coming into elastic search unstructured which increases the time it takes to sift through logs.

We also don't have runbooks on the registry.  If something were to happen we don't have any details of where to look, troubleshoot, and diagnose issues.

Utilize this issue as research into areas where we can improve the overall stature of how we monitor and alert on issues related to the docker registry bits of infrastructure.  Create issues upon completion of the research that will address each of the potential areas for improvement with appropriate acceptance criterion as you see fit.

Story points: 2.0
Rake task for updating our vaults misconfigured

Example run:
```
rake 'edit_role_secrets[dev-gitlab-org]'
-> bundle exec knife vault edit dev-gitlab-org _default --mode client
-> bundle exec knife vault update dev-gitlab-org _default --clean -S(roles:dev-gitlab-org OR role:dev-gitlab-org) AND chef_environment:_default -Aabrandl,ahanselka,ahmadsherif,alejandro,jarv,jjn,stanhu,yorickpeterse,dsmith,devin,skarbek,craig --mode client
WARN: No clients were returned from search, you may not have got what you expected!!
✓ Switching to master (0.11 sec)
✓ Pulling from git@dev.gitlab.org:cookbooks/chef-repo.git (7.71 sec)
-> bundle exec knife download data_bags/dev-gitlab-org
Updated data_bags/dev-gitlab-org/_default_keys.json
Updated data_bags/dev-gitlab-org/_default.json
-> git add -A data_bags/dev-gitlab-org
-> git commit -v data_bags/dev-gitlab-org
Aborting commit due to empty commit message.
Failed: git commit -v data_bags/dev-gitlab-org
```

1. It's pulling from `dev` when it should be pulling from `ops`
1. It didn't properly search `roles:dev-gitlab-org`
    * The dev node is clearly part of this role as shown by `knife node show dev.gitlab.org`

Either fix the rake task appropriately, or update the documentation and remove this rake task.

Reference: https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5439#

Story points: 1.0
[PagerDuty] SSLCert expiring soon: dev.gitlab.org

## Summary 

### Issue
We got paged for the following incident - Certification for dev.gitlab.org is expiring on 11/10/18 23:59:59PM GMT

### Investigation 
According to the [runbook](https://gitlab.com/gitlab-com/runbooks/blob/master/troubleshooting/ssl_cert.md), ran the command to look at the certification detail.

```
echo | openssl s_client -showcerts -servername dev.gitlab.org -connect dev.gitlab.org:443 2>/dev/null | openssl x509 -inform pem -noout -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            42:75:ea:82:ef:98:ba:ac:46:e2:a7:dc:66:ba:ca:c7
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
        Validity
            Not Before: Nov  9 00:00:00 2017 GMT
            Not After : Nov 10 23:59:59 2018 GMT
```

Tried to renew it but got an error:

```
sslmate renew dev.gitlab.org
If you don't have an account yet, visit https://sslmate.com/signup
Enter your SSLMate username: gitlabops
Enter your SSLMate password: ********************************
Authenticating... Done.
Tip: if you don't want to have to type your password every time, you can run 'sslmate link' to link this system with your account.

Error: the certificate for dev.gitlab.org is not about to expire.
Tip: to reissue this certificate, run 'sslmate reissue dev.gitlab.org'.
Tip: use --force to override the above error.
```

So not sure if we need to force it or wait. Will check with the team on (the practice) since we still have time. 

### Root Cause
This is not really an issue. A pre-cautionary alert. 

### Action Items
[ ] Renew the certificate

Story points: 1.0
Access to production database

Hello,

I would like a read only access to the secondary production database to run explains on some tricky queries for Issue https://gitlab.com/gitlab-org/gitlab-ee/issues/7851 

Can you set up an access just like you did in https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/4355 ?
The hostname in the response there doesn't exists anymore so I guess my access didn't survive the move to GCP.

Here is my SSH public key:
```
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArTflMdTi+WGL0qptp5bJWnRBx54nOMmvYx8G66gigpjnjKqKV2c7NVf/wIo8G6pWzdj4XAOwnjUSERran5cJbpj/SqD0ah9Fr2xYZ7HcvmqasXejnrizRGdfIjCJPLTP8C77wrZ5a13+H4Rg3MN+B8E9i5/wsMvgwgkz6jagkIk8RFyQbs/8iULVdhYnNiosNYkFDA8c9AzoThS1EwOT0namQBU/T1t1IMbqxXJSv1cY9k01hMW6sdytl9XmQu9mk6FDlxQKwYTpbKzxo/cRE2ez3nhSKo5cAL3NAciQbDLQKgTDnnNMpT1oZbHOdNFsdnAwrmrPl4kwLCEeK+2UjQ== groulot@gitlab.com
```

Story points: 1.0
Root device on postgres primary runs out of space

The device for `/` is only 20GB in size and may fill up completely. Since `/tmp` is on that disk, it may cause problems with postgres backups (I have a weak suspicion in the direction of https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5434).

Can we increase the size to 100GB for all postgres hosts ? Is it possible to do an online resize?

gprd primary: https://dashboards.gitlab.net/d/bd2Kl9Imk/host-stats?refresh=1m&panelId=14&fullscreen&orgId=1&from=now-7d&to=now&var-environment=gprd&var-node=postgres-03-db-gprd.c.gitlab-production.internal&var-promethus=prometheus-01-inf-gprd

Even though that does not indicate it ever went to 0, it doesn't mean it didn't: It takes only a few seconds to write out 20 GBs worth of data and hit the bottom, the process would fail, clean up and we would never notice in prometheus.

/cc @gitlab\-com/gl\-infra

Story points: 2.0
Redirect developer pages to backend engineer pages

After https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/15669 and https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/16096, we need these redirects:

* `/job-families/engineering/developer/` -> `/job-families/engineering/backend-engineer/`
* `/handbook/engineering/career-development/junior-developers/` -> `/handbook/engineering/career-development/junior-engineers/`

Story points: 1.0
*Triggered #3777:* Firing 1 - CPU use percent is extremely high on postgres-dr-archive-01-db-gprd.c.gitlab-production.internal for the past 2 hours.

## Summary

### Issue
CPU utilization alert triggered for: postgres-dr-archive-01-db-gprd.c.gitlab-production.internal

### Investigation
Bunch of wal-e processes appear to be taking up most of the CPU but CPU has been utilized > 90% for quite some time (though it spiked down below 90% at times as well). In postgresql log, we see errors indicating absolute URIs not being able to be loaded - which could be causing the CPU jump. A PD incident# 3776 was also fired earlier for postgres-dr-delayed node for a delayed replica and the node was also consuming high CPU. (Could be related and we decided to wait until POC in EMEA looks at it). For detailed investigation, see comments below.

### Proximal Root Cause
The URIs that could not be loaded might be causing retries and/or subsequent tasks/steps not to be completed properly causing loops and consequently causing high CPU utilization. Since this is not yet a definite root cause, hence the name: "proximal". 

### Mitigation
The alert cleared on its own for now. But we might have to suppress the alarm for the same reason as PD incident#3776. 

### Action Items
- Monitor the CPU and if the alarm goes off again and we see the same symptom (logs), then suppress the alert in AlertManager
- Inform POC in EMEA (@abrandl) about the incident to see if both #3776 and #3777 are things he can help us look into and root cause 


Story points: 1.0
PostgreSQL_ReplicationLagTooLarge_DelayedReplica Alert

We are getting an alert for PostgreSQL_ReplicationLagTooLarge_DelayedReplica in production.  It appears that the delayed replica is still trying to use s3 for the wal-e replication.

Slack thread is at:

https://gitlab.slack.com/archives/C101F3796/p1541120049182300

Story points: 1.0
Complete Phase 2 of TLS1.0/1.1 End of Support

https://gitlab.com/gitlab-com/gl-security/engineering/issues/202#2018-phase-2-complete-this-phase-by-end-of-november-15-2018

Notes are in the issue above.  To be completed Nov 15, but putting the 12th for due date to remind us earlier.

Story points: 1.0
301 Redirects

As a follow up to the [Website IA](https://gitlab.com/gitlab-com/marketing/general/issues/3078) we need several 301 redirects put in place (including the team page) 

The list of redirects is in this Google sheet: https://docs.google.com/spreadsheets/d/1yReGphpeGjqy3hoUYl8jaudqNS1fHXDKlbGhHxrsfwA/edit#gid=0

cc @northrup @williamchia

Although we have JS redirects in place (which ensures people can get to the page after a small delay), Google is not picking up on the route change. For example, pages are still showing up at `/features/` even though they've been moved to `/solutions/`. A 301 redirect is the only reliable way to communicate change to search engines. 

as one example https://about.gitlab.com/features/github/ should be https://about.gitlab.com/solutions/github/ but it shows up incorrectly in SERPs: 

![image](/uploads/2ac346f6b0f8309e63c71a06d8cf1753/image.png)

Story points: 2.0
Add gitlab-bot triage to the infrastructure and production issue queue

Here are some rules that I think we should implement to start:

* gitlab-bot https://gitlab.com/gitlab-bot
* https://gitlab.com/gitlab-org/gitlab-triage

## Rules

- Incident issue without severity label
- Incident issue without attribution label `Service.*`
- Infrastructure issue without weight
- Comment and maybe close issues with xxx days of innactivity


Story points: 2.0
Error when deploying customers.gitlab.com

```
================================================================================
  Recipe Compile Error
  ================================================================================
  
  Chef::Exceptions::RecipeNotFound
  --------------------------------
  could not find recipe server for cookbook postgresql
  
  Cookbook Trace:
  ---------------
    /var/chef/cache/cookbooks/cookbook-customers-gitlab-com/recipes/database.rb:9:in `from_file'
    /var/chef/cache/cookbooks/cookbook-customers-gitlab-com/recipes/default.rb:11:in `from_file'
  
  Relevant File Content:
  ----------------------
  /var/chef/cache/cookbooks/cookbook-customers-gitlab-com/recipes/database.rb:
  
    2:  # Cookbook Name:: cookbook-customers-gitlab-com
    3:  # Recipe:: database
    4:  # License:: MIT
    5:  #
    6:  # Copyright 2016, GitLab Inc.
    7:  #
    8:  include_recipe 'gitlab-vault'
    9>> include_recipe 'postgresql::server'
   10:  
   11:  customers_gitlab_conf = GitLab::Vault.get(node, 'cookbook-customers-gitlab-com')
   12:  
   13:  package 'libpq-dev'
   14:  
   15:  bash 'create database user' do
   16:    user 'postgres'
   17:    code "psql -c \"CREATE USER \\\"#{customers_gitlab_conf['database_user']}\\\" WITH PASSWORD '#{customers_gitlab_conf['database_password']}'\""
   18:    not_if "sudo su - postgres -c \"psql -c '\\du' | grep #{customers_gitlab_conf['database_user']}\""
  
  Platform:
  ---------
  x86_64-linux
  
  
  Running handlers:
[2018-10-31T22:11:52+00:00] ERROR: Running exception handlers
    - PrometheusHandler
  Running handlers complete
[2018-10-31T22:11:52+00:00] ERROR: Exception handlers complete
```

@skarbek

Story points: 1.0
Unable to publish new version of  gitlab-postgresql

When trying to publish the `gitlab-postgresql` cookbook, it fails.  The chef-repo has this pinned to `0.1.0` in the Berks file. 
 In the process of updating the Berksfile for our chef-repo, I'm unable to resolve a dependency conflict.  Berks doesn't actually tell me where the conflict lies, and ends up resulting in it's inability to satisfy a long list of requirements.

Reference: https://ops.gitlab.net/gitlab-cookbooks/gitlab-postgresql/pipelines/8228

Story points: 1.0
High CPU on the web fleet after 11.4.2 release

The load on the web fleet increased on the 26th at ~09:00. This is around when we deployed *v11.4.2-ee.0* to gprd.

![Screen_Shot_2018-10-31_at_3.10.43_PM](/uploads/7082bba7508d0fb8a915f1954a626d7f/Screen_Shot_2018-10-31_at_3.10.43_PM.png)

https://dashboards.gitlab.net/d/RZmbBr7mk/gitlab-triage?refresh=30s&panelId=1176&fullscreen&orgId=1&from=now-30d&to=now

web-04 is in a current state of alarm so i used it as an example below:


![Screen_Shot_2018-10-31_at_3.05.17_PM](/uploads/7209aa9f3c1d17d7aa99295a93be0752/Screen_Shot_2018-10-31_at_3.05.17_PM.png)

https://dashboards.gitlab.net/d/bd2Kl9Imk/host-stats?orgId=1&from=now-14d&to=now&refresh=1m&var-environment=gprd&var-node=web-04-sv-gprd.c.gitlab-production.internal&var-promethus=prometheus-01-inf-gprd


![Screen_Shot_2018-10-31_at_3.03.18_PM](/uploads/f3c05dc6363f78d82b76414f673d1a99/Screen_Shot_2018-10-31_at_3.03.18_PM.png)


![Screen_Shot_2018-10-31_at_2.51.35_PM](/uploads/73ffe7598f7bb054bd90998aae3f4dd5/Screen_Shot_2018-10-31_at_2.51.35_PM.png)

For a ruby process that is using a full cpu:

```
# perf record -F 99 -p 15962 -g -- sleep 60
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.918 MB perf.data (3585 samples) ]
# perf script > out.perf
# ./stackcollapse-perf.pl out.perf > out.folded
# less out.folded
#  ./flamegraph.pl out.folded > kernel.svg
```


![kernel.svg](/uploads/7607bed3215a8682a791a5fd46e68448/kernel.svg)

Story points: 2.0
Change backups for the gitaly fleet

Actually, we execute backups each 24h. 
https://gitlab.com/gitlab-restore/gitlab-production-snapshots

The idea is to execute every 12 hours Initially, in further iterations we could go to 6 hours and 3.

In case of a disaster, we will reduce the data lost, and the effort seems to be smaller as spoken with Jarv.

@jarv @glopezfernandez @dawsmith @andrewn - Any thoughts on that?

Story points: 1.0
GitalyLatencyOutlier Alert in Staging

The following alert is coming up in staging repeatedly.  It stays on for about 5 minutes, then resolves itself.  If this is a problem, we should fix it.  If it's not, we should fix the alert.


```
Gitaly: Latency on the Gitaly ListBranchNamesContainingCommit is unusually high compared with a 24 hour average

 The error rate on the ListBranchNamesContainingCommit endpoint is outside normal values over a 12 hour period (95% confidence). Check https://dashboards.gitlab.net/dashboard/db/gitaly-feature-status?var-method=ListBranchNamesContainingCommit&var-tier=stor&var-type=gitaly&var-environment=gstg&refresh=5m


 **
 Gitaly: Latency on the Gitaly ListBranchNamesContainingCommit is unusually high compared with a 24 hour average

 The error rate on the ListBranchNamesContainingCommit endpoint is outside normal values over a 12 hour period (95% confidence). Check https://dashboards.gitlab.net/dashboard/db/gitaly-feature-status?var-method=ListBranchNamesContainingCommit&var-tier=stor&var-type=gitaly&var-environment=gstg&refresh=5m

:label: *Labels*:

 *Alertname*: GitalyLatencyOutlier
 *Channel*: gitaly
 *Environment*: gstg
 *Grpc_method*: ListBranchNamesContainingCommit
 *Monitor*: gstg-default
 *Provider*: gcp
 *Region*: us-east
 *Severity*: warn
```

Story points: 1.0
Add version constraints on cookbook publisher

Per discussion in [this comment](https://gitlab.com/gitlab-cookbooks/gitlab-postgresql/merge_requests/1#note_113276171) our chef cookbook publisher script is currently inserted into the CI pipelines via a simple git clone, with no version locking or other mechanisms in place to ensure that changes to the tooling don't inadvertently break downstream cookbook pipelines. That publisher script should be repackaged as a gem and included in the Gemfile with appropriate version pinning (or implement an equivalent control, e.g. tagged references on git clone, etc.)

Story points: 3.0
301 Redirect: /company/culture/remote-only/ to /company/culture/all-remote/

I've opened [a merge request](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/16038/diffs) that renames the directory /company/culture/remote-only/ as /company/culture/all-remote/. Before we merge (preferably), I'd like to setup a redirect for each of the two affected URLs

1. https://about.gitlab.com/company/culture/remote-only should redirect to https://about.gitlab.com/company/culture/all-remote
1. https://about.gitlab.com/company/culture/remote-only/building-all-remote should redirect to https://about.gitlab.com/company/culture/all-remote/building-all-remote

Thanks in advance for your help!

Reference https://gitlab.com/gitlab-com/www-gitlab-com/issues/2745

Story points: 1.0