Skip to content

Step 1 (16.1) Reverting part of adding organization_id to namespaces

Omar Qunsul requested to merge 412771-revert-organization-contains-namespaces-2 into master

What does this MR do and why?

Reverting part of adding organization_id to namespaces

Revert the problematic part of: !120822 (merged) And running the schema changes in post-migration instead

Changelog: removed

Here are my thoughts about how to prevent this from reaching self-managed customers:

In milestone 16.1:

  • (1) We remove any model association or functionality that assumes that the newly added column exists. Which we have to do, because the column won't be added anymore. Like what Alex did in his original revert MR
  • (2) We move the migration/index/LFK creation to post-migrations (guarded with if statements) instead! My goal is that let's bring the self-managed database schema as close to our GitLab.com database as soon as possible. In case customers upgrade from 16.0 to 16.1. Which might be the common case. We are moving these migrations to Milestone 16.2 instead as normal migrations. See this thread

At this stage:

  1. Environments that were impacted before (like SaaS Gitlab) don't run the post-migrations, because they are guarded with if statements. So basically it won't change anything. We can validate via the gitlabdotcom database testing pipeline as well.
  2. Environments that were not impacted, will run the post-migrations, but the fixes on the UNION are already running and deployed. So the application won't be affected, and won't throw 500s

In milestone 16.2:

  • We bring back the associations (Organization has many Namespaces) again for everyone. We revert Point (1) above.

Multi Milestone Upgrades

But we have a problem, which is if customers upgrade straight from 16.0 to 16.2 (for example), the post migrations are going to run after the deployment. They deploy version 16.2, but run post-migrations from 16.1. Which will cause problems. Because the associations will be deployed before the schema changes. To resolve this we can:

  1. Introduce a Required Stop at 16.1 Most probably not recommended, but listing it as an option. So they are required to run the post-migrations before they deploy 16.2.
  2. The post-migrations that I suggest we do in 16.1, we do in 16.2 instead as normal migrations instead. So that in 16.1 we just deliver the application fixes (Thong's MRs). In 16.2 we deploy the schema changes and maybe the associations.

According to the answers from @alexives here (internal slack link), if customers do upgrades for more than 1 milestone, they are expected to take the application down anyway.

Addressing: #412771 (closed)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #412771 (closed)

Edited by Omar Qunsul

Merge request reports