We want Aegir to be able to backup and migrate itself. Right now, we assume that it is installed in sites/default
which makes it impervious to tasks and things like that (see #453540: consider the 'default' site like a regular site, with exceptions for that particular issue). Aegir should be installed in a real sites/fqdn
directory and processed like the others, with some exceptions. In particular, "restore" actions should be very carefully performed, with lots of warning, and maybe followed by a system-wide platform verification. "Disable" should be forbidden altogether.
The biggest hurdle in getting hosting to upgrade itself is how we manipulate the task log. When the log is written to the database, the DB may have changed names or the table may have changed structure. The first part has an easy fix: reload the DB credentials before writing the log. The second part is more tricky: I don't think there's an easy solution and **some** upgrades will have to be performed manually.
But it would be important to be able to upgrade from (say) Drupal 5.14 to 5.16 (without changes to the hosting DB structure) automatically.
Comment | File | Size | Author |
---|---|---|---|
#7 | hosting_hostmaster_migrate.patch | 3.58 KB | adrian |
#7 | provision_hostmaster_migrate.patch | 2.66 KB | adrian |
Comments
Comment #1
anarcat CreditAttribution: anarcat commentedHosting setup needs to be rerun (and rerunnable) when migration of aegir is be finished so that the cronjob gets fixed.
Comment #2
adrian CreditAttribution: adrian commentedhttp://drupal.org/node/319277#comment-1634440
SO it's kind of working.
We still need to change setup to replace the arguments to hosting dispatch.
That regex will handle it for us.
I just committed the re-runnable setup command, so the master site is now fully manageable, for everything but installs (which we won't be able to do until d6).
Closing this.
Comment #3
anarcat CreditAttribution: anarcat commentedSo that's nice: we can deploy a new site using the backend, but what about the frontend? We have yet to be able to migrate Aegir itself, from the frontend. I think it's a reasonable goal.
Comment #4
anarcat CreditAttribution: anarcat commentedSo I'll be posting the migration instructions in the UPGRADE.txt file. I found two bugs during testing, in the backup system, which i fixed in those commits:
http://drupal.org/cvs?commit=217648
http://drupal.org/cvs?commit=217654
I also had to verify the d6 platform through the web interface first, because otherwise it would fail like this:
Comment #5
anarcat CreditAttribution: anarcat commentedWe are likely to need the #500362: dispatcher locking if we want to run concurrent frontend installations (which is probably required to have the frontend upgrade itself.
Comment #6
anarcat CreditAttribution: anarcat commentedSee also #588114: cannot upgrade aegir with itself because the frontend doesn't follow.
Comment #7
adrian CreditAttribution: adrian commentedHere are the patches for the new hostmaster migrate command.
These patches add a new command to provision which can be used as :
drush --root=/path/to/old/platform hostmaster migrate example.com /path/to/new/platform --debug
I'd suggest having exact copies of the hostmaster platform on two different versions of drupal core, for testing right now.
ie: migrate hostmaster HEAD on drupal 6.10 to hostmaster HEAD on drupal 6.14
to handle migrations from previous versions of hostmaster to ones after this patch lands, we will need to (for now) be tolerant of the 'hostmaster park' command not being available, and possibly fall back on just disabling the queue by hand (it's not perfect but it should work in almost all cases).
i'm also pondering the idea of shipping a drush_make file alongside provision, so it can roll out the latest version of the interface.
Comment #8
anarcat CreditAttribution: anarcat commentedSo the current state of affairs is this:
1. we can migrate a hostmaster site using the hostmaster-migrate command, in the backend
2. the UPGRADE.txt recommends the hostmaster-migrate process
3. we cannot yet provision-install hostmaster sites (see #711740: allow install of hostmaster sites in provision-install)
4. the install process can setup only provision or the whole thing, but lacks some glue to run hosting-setup and other things (#711760: separate backend and frontend install process)
5. we cannot yet migrate or clone hostmaster sites from the frontend (see #711746: allow upgrade of hostmaster sites from the frontend)
Once all this is done, we can change the project name to Skynet, a few expert systems, neural networks and new AI thingies, hook it up to some nukes, and watch the fireworks. ;)
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedOnly 5.) is left now :)
Comment #10
anarcat CreditAttribution: anarcat commentedJust a note here to mention that #500362: dispatcher locking was implemented, which theorically makes it possible to run the frontend dispatcher on multiple servers at once.
Comment #11
Steven Jones CreditAttribution: Steven Jones commentedComment #15
ergonlogicClosing in favour of #711746: allow upgrade of hostmaster sites from the frontend