## Context This is part of https://gitlab.com/groups/gitlab-org/-/epics/8602+, which aims to make the offline migration process ready for GA on self-managed installs. ## Problem On of the questions we need to ask is how much time customers can expect to need to perform an offline migration of their registries. This estimate depends on many variables, among which we can highlight the overall registry size in bytes and the used storage backend. ## Goal To answer this question, we need to perform tests against test registries of different sizes and using different storage backends, starting with GCS, S3, and the local storage filesystem. --- #### Single Step 1️⃣ | Registry Size \ Storage Backend | GCS | S3 | Filesystem | | ------ | ------ |------ |------ | | 100GB | 52 minutes | 8 minutes | N/A | | 500GB | 4 hours 15 minutes | 41 minutes 28 seconds | N/A | | 1TB | Scheduled | Scheduled | - | | 10TB | TBD | TBD | TBD | | 100TB | TBD | TBD | TBD | | 1PB | TBD | TBD | TBD | #### Multi Step 3️⃣ | Registry Size \ Storage Backend | GCS | S3 | Filesystem | | ------ | ------ |------ |------ | | 100GB | one: ~23 min.; two: ~2 min.; three: ~27 min. | one: 6 min. 11 sec.; two: 16 sec.; three: 1 min. 26 sec. | N/A | | 500GB | one: 2 hours 3 min; two: 9 min 16 secs; three: 2 hours and 36 min | one: 20 min ; two: 90 sec ; three: 5 min and 45 sec | N/A | | 1TB | Scheduled | Scheduled | - | | 10TB | TBD | TBD | TBD | | 100TB | TBD | TBD | TBD | | 1PB | TBD | TBD | TBD | The sizes above are only for illustration purposes, we should find out the most sensible set of sizes to use. While doing this exercise, we are considering the GitLab self-managed [reference architectures](https://docs.gitlab.com/ee/administration/reference_architectures/). --- ### Plan * Phase one - [Preparation](https://gitlab.com/gitlab-org/container-registry/-/issues/1099) (in Q3) :white_check_mark: * Phase two - Fine-tuning (in Q3) - [Container Registry Cloud Seeder](https://gitlab.com/gitlab-org/ci-cd/package-stage/container-registry-seeder) to help automate the scaling of necessary seeding * Phase three - 100GB (in Q3) :white_check_mark * Phase four - 500GB (in Q3) :white_check_mark: * Phase five - 1TB (in Q4) :point_left: milestone: %"16.7" #### Execution 1. Use of [team cloud sandbox](https://gitlabsandbox.cloud/cloud) to deploy GCP and AWS infrastructures 2. Deploy a 1K Reference Architecture using GET: [docs](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/blob/main/docs/environment_prep.md) | [configs](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/tree/main/examples) 3. Create a Personal Access Token on the GitLab Instance 4. Clone and configure the Container Registry Cloud Seeder according to [instructions](https://gitlab.com/gitlab-org/ci-cd/package-stage/container-registry-seeder/-/blob/master/README.md?ref_type=heads) 5. Run the seeder against the GitLab instance (using the token created on step 3 for authentication) 6. Verify seeding is complete and destroy seeding VMs using Terraform 7. Install a [database](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/database-local-setup.md) on the GitLab instance and run the migration tool following the [docs](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/database-quick-start.md) provided 8. Take note of performance 9. Teardown the GitLab instance #### Cost Analysis Infra Items: * 1K Reference Architecture GET * VM seeder machines * Static IPs * Cloud buckets (GCS/S3) Breakdown: * GCP: - 100 GB: $7.06 - 500 GB: $12.06 * AWS: - 100 GB: $7.08 - 500 GB: $9.37