theforeman
Fixes #38319 - Fix Ansible Tower FQDN migration
Updated the migration to bypass validations and callbacks for reliable record updates.
(cherry picked from commit 1c142e3d416d8749708531dae8ad9551d32966bf)
Since it's too late for the 3.14 release, should we keep it for 3.14.1, or would it be better to create a new PR with an updated migration to fix this one?
Since it's too late for the 3.14 release, should we keep it for 3.14.1, or would it be better to create a new PR with an updated migration to fix this one?
One complication with introducing a new migration is that the migration path becomes different depending on how the user upgraded. Consider the following paths:
- 3.13.0 -> 3.14.0 -> 3.14.1 -> 3.15.0
- 3.13.0 -> 3.14.1 -> 3.15.0
This will result in different paths and different entries in the applied migrations DB.
I'm not sure what's ideal here. Changing migrations is generally not a nice thing since it can make debugging harder.
I'd be tempted to fix it up in develop where we drop the old migration and introduce a new fixed migration. Then cherry pick that together with this.
@evgeni do you have any opinion on this?
@ekohl , we have two options:
- only fix the original migration (which will result in probability of invalid records for people who already migrated with the old code)
- fix the original migration (to make sure we don't have errors down the line) and introducing additional migration to both 3.14.1 and develop.
For 2 it means that the migration state will be the same for all possible migration paths and the data will be fixed to everyone: People who already migrated with the "bad" migration will need to apply only the new one that will fix their state. People who did not migrate with the old migration, will run the "fixed" migration and then the new migration, that will be a noop for them. This way both groups will have both migrations in the DB state, and both groups will have fully correct DB state.
The only concern here, is that we introduce two migrations that basically act as one.
@nofaralfasi Any updates on the progress of this?
Waiting on @ekohl's response to determine how to proceed, as @ShimShtein outlined the two available options in the comment above.
@nofaralfasi do you still think we should pull this into 3.14 or is it something we can leave for 3.15?
@nofaralfasi do you still think we should pull this into 3.14 or is it something we can leave for 3.15?
This PR addresses an edge case where a user registers hosts using host groups with a newer version of AAP. I recommend including it in 3.14, even though it’s not strictly required.