Skip to content

Resolve "Background migrations removed issues" (backport to 17.1)

Ryan Wells requested to merge 475192-backport-1.71 into 17-1-stable-ee

What does this MR do and why?

Backport to %17.1 for #475192 (closed)

Two batched background migrations were accidentally finalized in %17.0 and removed in %17.1. This causes an error for customers attempting to upgrade from 16.11 to 17.1, .2 and .3 .

We are reverting that change now to re-add the missing migrations and enable customers to upgrade. It is marked as a priority1 as self-hosted upgrades are blocked and severity2 / severity3 as while there is a workaround (stopping at an unannounced version) that isn't a reasonable workaround for self-hosted customers, which is why we're backporting.

Original slack thread is here (internal)

Relevant slack content
Name Message
Ryan Wells 👋  Hi team. I think I'm in the right place, but please redirect me if not! FYI - two batched background migrations were accidentally finalized in %17.0 and removed in %17.1. It has been brought to our attention and we are reverting that change now to re-add the missing migrations.This is the revert MR, here is the issue and original MR. Michał is taking the lead on this on our side. Are there any other steps we should take here? We don't think we need to backport this but would rather check just in case.
Dat Tang Hi Ryan 👋 Is this just an issue on 17.1? If so, why don't we need a backport to 17.1?
Ryan Wells Customer example going from 16.11.7 to 17.1.2 failing due to missing migrations. Definitely looking for your advice here so that we do the right thing!
Dat Tang example: so if a customer update from 16.11 directly to 17.2 , they still face this issue, right?
Ryan Wells I would expect so, yes. We haven’t actually tried this out but I’m pretty sure we would see the same issue
Dat Tang so, in this situation, since we missed 17.3 already (it was tagged a few hours ago), you need to put this revert into the next patch release, which is next week. You will need to make 3 backports, for 17.1, .2 and .3. Do you think it makes sense?
Ryan Wells I think so - yes! Thank you for keeping us right Dat 🙂

MR acceptance checklist

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

  • This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
  • The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
  • This MR has a severity label assigned (if applicable).
  • Set the milestone of the merge request to match the target backport branch version.
  • This MR has been approved by a maintainer (only one approval is required).
  • Ensure the e2e:package-and-test-ee job has either succeeded or been approved by a Software Engineer in Test.

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

Edited by Ryan Wells

Merge request reports