London hackfest April 2017 - Upgrade performance discussion notes

Part of London hackfest April 2017.

1. sam's crazy idea

• Split upgrade stesp (in upgrade.php) into separate files or something, with metadata for each step
• Categorise upgrade steps into ones that can safely run before the upgrade downtime, after it, or must run during it.
• This would be optional (it tracks if you did it, so if you didn't, you get them during normal upgrade
• ISSUES: Some people would still be worried about making production changes even if the 'before' changes are supposed to not affect anything...

2. Timestamp update steps

• Could the upgrade display how long each step took (in the CLI/web output)
• Would it be nice to log them in mdl_log too?
  • No wait that's probably a nightmare because of what if somebody observes it...

3. Scheduled downtime UI

• It ouwld be nice to display a banner like 'The system is going down iun 30 minutes' (similar to unix shutfown)
• I think Catalyst made a plugin that does this
• Should it be in core? Interface in the current maintenance mode settibgs, just an option to schedule it there. Should have a choice between ending in 'soft' or 'hard' maintenance mode
• Dan says this is already in core!!

4. Version upgrades that don't have upgrade.php type changes

• When only upgrading one plugin and not the whole system - sometimes you need to up[grade a plugin version without any need for downtime - lang string, JS, or CSS. You only need purge caches plus it's nice to indicate that the version changed.
• Possible solusion - two verison numbers, 'soft' and 'hard'. Can work basically the same way but the sfot one only does a purge cahces
• Needs to indicate in the plugin upgrade UI (cli.web) whether the upgrade will require a proper upgrade or not.

5. Read-only copy

• One institution runs a read-only copy of the site - with capabilities set so they can't do it