The warnings and errors about updated/missing modules that you seen when comparing two platforms (prepping for migration) may be stale if you have enabled a module after the site was last verified. This could result in accidentally migrating the site to a platform with missing or wrong versions of modules, even thought the comparison tool erroneously reports that everything is okay.
For example:
1) Create two identical platforms, A and B
2) Create a site on Platform A. Enable a particular module, and then DELETE that module from platform B.
3) Migrate the site from Platform A to Platform B. Expected behavior: Aegir generates an error and blocks the migration, because Platform B is missing an enabled module. Actual behavior: Aegir goes ahead and migrates the site, which is now missing the enabled module.
I'm not sure what the solution is- perhaps re-verify the site as part of the migrate task, and if anything has changed since the previous verification, abort the migration. With this solution, the 'comparison' UI may still be stale, but it pretty much guarantees nothing unintended will happen.
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedMmm. We had a big discussion about this over here once: http://drupal.org/node/956998#comment-3649144
I agree invoking a verify would probably help here. There's some lingering concern that it will make Migrations even slower than they are (especially for multiserver), and also that we need to invoke the verify 'from the frontend' so that the Hosting post-verify hooks run (as they update the package schema). Such an invocation might be asynchronous to the migrate task if it enters the queue afterward, which might cause problems..
Comment #2
omega8cc CreditAttribution: omega8cc commentedSite re-verify will not help here at all.
It is rather documentation candidate, because there is no other method to update the records for comparison than running re-verify of both old and new platform (not site) before trying to migrate the site (and check the comparison list).
Comment #3
Dane Powell CreditAttribution: Dane Powell commentedWell the problem could arise either by enabling a module on Platform A that doesn't exist on Platform B, and then trying to migrate from A to B, in which case re-verifying the site beforehand WOULD help- or, the problem could arise because an enabled module is deleted from Platform B, in which case re-verifying the platform would be necessary.
Comment #4
omega8cc CreditAttribution: omega8cc commentedNo, site re-verify never really helps here, because it is not the site which is compared by Aegir on migration. It does check which modules are enabled/disabled on the site, but it compares *platforms only*, so relying on what is available/enabled in the site can only give you an illusion of updated status for comparison. You always have to re-verify platforms first - both source and target, so it is not possible to do it "on the fly" during site migration.
Comment #5
Dane Powell CreditAttribution: Dane Powell commentedThe more I think about it, the bigger this issue seems to be- how can you ever safely enable a module on any site managed by Aegir? In other words, how can you ever enable a module and guarantee that it won't get lost during a migration? The only way I can imagine is to have a very strict policy of always building platforms from make files, and never manually downloading modules for a platform- even for development platforms. In essence, you can't rely on Aegir's comparisons at all. They become not only useless, but potentially dangerous.
I know that's a bit dramatic, but seriously- Aegir is providing some pretty bad / potentially dangerous misinformation with those comparisons. There should at least be a big warning at the top saying "This comparison may not be accurate".
EDIT: Well, I guess one other way to be safe is to always re-verify platforms/sites before migrating. But if we can do this, why can't Aegir do it automatically?
Comment #6
Steven Jones CreditAttribution: Steven Jones commentedI guess a better way to handle this would be to do a full-check in the validate phase of the migration task, and if a problem is detected, fail there? We could even schedule re-verifies of the platforms involved there and then, or just post a message about it for the user to discover.
Comment #7
Steven Jones CreditAttribution: Steven Jones commentedI think this is a bug report.
Comment #8
gboudrias CreditAttribution: gboudrias commentedThis new issue attempts to deal with certain problems raised in this one: http://drupal.org/node/1928442
Comment #9
omega8cc CreditAttribution: omega8cc commentedOur solution in BOA is to automatically run extra verify tasks for both source and target platform and the site itself as a part of migration task, so before it effectively proceeds with migration, Aegir internal database related to both platform and the site gets updated. It also solves other issues.
See for reference: http://drupalcode.org/project/barracuda.git/blob/HEAD:/CHANGELOG.txt#l417
The patch: http://drupal.org/node/1004526#comment-5843080
Comment #10
ergonlogicThe 6.x-2.x branch will go EOL along with Drupal this week. So I'm closing this issue. If it remains a confirmed issue in 7.x-3.x, feel free to re-open, or better yet, create a new issue referencing this one.