(possibly bad idea)
been speculating about a way to reduce downtime for Moodle upgrades by
doing part of the upgrade before actually taking the system offline. This is a lot more complicated than you might think.
The attached document is my idea for how that might be achieved - including a summary of the benefits and limitations of the approach.
If this gets anywhere near actually happening I will obviously make a Moodle Tracker issue and so on. At present, I don't have any time allocated for this and it's not a priority for my employer, but that might change...
This there any grounds for looking at whether or not it's possible to isolate and upgrade only parts of Moodle?
This would be good for "core" shared parts, but the impact of having to do downtime for the whole service to upgrade 1 module (e.g. for a bug fix) is a bit problematic.
Imagine if just a plugin could be put into maintenance mode (for sake of arguments lets say assign is 'optional' ):
- Admin puts "assign" into maintenance mode
- All end-user (including all admin pages) facing elements would be disabled (i.e. a request for anything in mod/assign/* is redirected to a disabled page)
- New scheduled tasks would be deferred
- Any existing events would be processed
- New events the plugin is interested in would be "queued"
- assign is now in maintenance mode
- Admin can replace the code
- Upgrade steps (for plugin) are run (these would have to be non-shared steps).
- Plugin is now in post-install mode
- Admin elements are re-enabled ( to allow configuration of new settings)
- Admin takes plugin out of maintenance mode
- Queued events are picked up and processed
- End-user elements are made accessible
- Plugin is now out of maintenance mode and fully usable again.
Nice idea! But, why stick to 'optional' plugins, it could work for core ones like mod_assign as well.
There are problems though - any type of plugin can have various callbacks that can affect any page in Moodle (for example the one that lets you insert HTML code after the header). Depending on the installation some of these things might not really be 'optional'...
I.e. it could automatically do the plugin upgrades as a second part of upgrade, with the opportunity to turn off maintenance mode at that point. Maybe it would work best like this:
- switch on full maintenance mode
- core part of upgrade completes
- switch off full maintenance mode, switch on plugin maintenance mode for each plugin requiring upgrade
- as each plugin upgrade completes, switch off maintenance mode for that plugin
What you propose is basically the opposite of what has been done a few times in the past, which in your terminology could be called post-upgrade steps.
The two examples I am thinking of are:
- The question enging changes in Moodle 2.1. Here, there was a long, complex upgrade of all the data about all quiz attempts ever. There was an option to not do all of the upgrade duing the main maintenance mode window. Instead, the attempte could be upgraded a bit at a time on cron aftewards (and there was code so that if you tried on access a quiz attempt were the data was not yet upgraded, you got an error saying to try again later).
- The new mod_assign, replacing mod_assignment. Here, the new feature was implemented as a new activity, with a conversion tool that could be run at any time. Of course, both had to be maintained for some Moodle versions, before conversion was made a compulsory pre-requisite in the Moodle release where the old assignment was removed.