London hackfest April 2017 - Upgrade performance discussion notes: Difference between revisions
From MoodleDocs
sam marshall (talk | contribs) |
m (Typos) |
||
Line 4: | Line 4: | ||
== 1. sam's crazy idea== | == 1. sam's crazy idea== | ||
* | * Split upgrade steps (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 == | == 2. Timestamp update steps == | ||
Line 13: | Line 13: | ||
* Would it be nice to log them in mdl_log too? | * 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... | **No wait that's probably a nightmare because of what if somebody observes it... | ||
* | * Sam working on this as MDL-58567 | ||
== 3. Scheduled downtime UI == | == 3. Scheduled downtime UI == | ||
* It | * It would be nice to display a banner like 'The system is going down in 30 minutes' (similar to unix shutdown) | ||
* I think Catalyst made a plugin that does this | * I think Catalyst made a plugin that does this | ||
* Should it be in core? Interface in the current maintenance mode | * Should it be in core? Interface in the current maintenance mode settings, just an option to schedule it there. Should have a choice between ending in 'soft' or 'hard' maintenance mode | ||
* Dan says this might already in core, but seems like it isn't - anyone want to take it? | * Dan says this might already be in core, but seems like it isn't - anyone want to take it? | ||
== 4. Version upgrades that don't have upgrade.php type changes == | == 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 | * When only upgrading one plugin and not the whole system - sometimes you need to upgrade 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 | * Possible solution - two version numbers, 'soft' and 'hard'. Can work basically the same way but the soft one only does a purge caches | ||
* Needs to indicate in the plugin upgrade UI (cli.web) whether the upgrade will require a proper upgrade or not. | * Needs to indicate in the plugin upgrade UI (cli.web) whether the upgrade will require a proper upgrade or not. | ||
== 5. Read-only copy == | == 5. Read-only copy == | ||
* One institution runs a read-only copy of the site - with capabilities set so they can't do it | * One institution runs a read-only copy of the site - with capabilities set so they can't do it |
Latest revision as of 10:54, 20 April 2017
Part of London hackfest April 2017.
1. sam's crazy idea
- Split upgrade steps (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...
- Sam working on this as MDL-58567
3. Scheduled downtime UI
- It would be nice to display a banner like 'The system is going down in 30 minutes' (similar to unix shutdown)
- I think Catalyst made a plugin that does this
- Should it be in core? Interface in the current maintenance mode settings, just an option to schedule it there. Should have a choice between ending in 'soft' or 'hard' maintenance mode
- Dan says this might already be in core, but seems like it isn't - anyone want to take it?
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 upgrade 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 solution - two version numbers, 'soft' and 'hard'. Can work basically the same way but the soft one only does a purge caches
- 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