This epic replaces https://gitlab.com/gitlab-org/gitlab/-/issues/229509. As part of ongoing efforts to remove the dependency of GitLab Pages on NFS, we are going to push all Pages NFS access in gitlab-rails into Sidekiq. The primary motivation for this is to allow us to start migrating gitlab.com Puma processes to Kubernetes. ## Background One of the drivers of urgency for this epic has been the [migration to Kubernetes of GitLab.com](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/112). Without Pages architecture moving into cloud native compatible direction, we will be unable to continue to scale GitLab.com both on the infrastructure but also on the application side. Current biggest blocker for the migration is the fact that our Web and Api fleet (which is essentially GitLab Rails with Puma) depend on the NFS (One of consumers being Pages). Given that scaling further is going to affect us on a shorter timeline, the Scalability team is going to help the Pages team get further ahead with this architectural change. ## Exit criteria 1. [x] Accessing Pages NFS from Puma raises a real error (https://gitlab.com/gitlab-org/gitlab/-/issues/239350) 1. [x] Handover work back to the stage group team: 1. [x] Create list of things we chose to not address 1. https://gitlab.com/gitlab-org/gitlab/-/issues/239331 ## Meeting notes https://docs.google.com/document/d/17kOcLA3UN8HzzUF-G26Tv3hZPvY61pulJKO6eDm-8_w/edit?usp=sharing - Recording: https://youtu.be/Mg0BOTffmiE ## Things that still access Pages NFS from Puma in production https://sentry.gitlab.net/gitlab/gitlabcom/?query=is%3Aunresolved+%22gitlab%3A%3Apages%3A%3Asettings%3A%3ADiskAccessDenied%22&sort=priority ## Status 2020-09-21 All Pages NFS access on GitLab.com now happens in Sidekiq, not Puma, and we've removed the feature flags. All Pages disk access from Puma will raise an error in any environment (development, staging, etc.). Pages NFS has been unmounted from the Web and API fleet in production.