Issue #2378
Updated by semyers about 8 years ago
A user reported https://pulp.plan.io/issues/2377 this evening, which is bad, because that migration (platform #25) was introduced in 2.11, and the user had just upgraded to 2.10.1. This is potentially a catastrophically bad thing, so I'm marking this urgent. I expect that this will result in a 2.10.2 hotfix.
mhrivnak was able to provide a workaround to the user reporting #2377, which we'll hopefully post soon.
I went through all of the issues currently MODIFIED for 2.11 and found the hashes of the related commits that erroneously appear on 2.10-dev:
9ac632e0d835eb580243c1c5cc781702a8ece117 https://pulp.plan.io/issues/2212
206cf5fd7bfd94cf994d528ac68019f143e92be8 https://pulp.plan.io/issues/1977
c4d73c7c5079d40f76812b745c55c8ea5f12f9cc https://pulp.plan.io/issues/2133
dd7c19bb12a0904ad0e5bc67e430f7c4c9d93a22 https://pulp.plan.io/issues/1069
6868481c1a0eeab06d1f18330e7fd7dc533d8007 https://pulp.plan.io/issues/1983
53e6c59c72eb2e4984d2e188e27f4ae0eebd68e9 https://pulp.plan.io/issues/752
0aa13525daad61991ac69ed780e24757eef37e40 https://pulp.plan.io/issues/2132
I've created a branch that rolls back all of these commits in reverse-chronological order on the current tip of 2.10-dev (the 2.10.1 release): https://github.com/pulp/pulp/compare/2.10-dev...seandst:fix-2.10-merge-forward
The new migration causes a tricky problem, though, because it shouldn't exist in 2.10.1, and *fails* in 2.10.1 with an unknown (but greater than 0) probability. So, not only do we need to fix migration #25, we probably need to turn it into a no-op in 2.10, and write a new migration #26 for 2.11 that isn't broken, and is aware that some version of migration #25 may have run in the past. That's just my current and uninvestigated thinking, so I'm open to ideas.
Right now I see it as a scenario where "you can't un-ring that bell".
.