Difference between revisions of "London hackfest April 2017 - Upgrade performance discussion notes"

Jump to: navigation, search
(2. Timestamp update steps)
m (Typos)
 
Line 4: Line 4:
 
== 1. sam's crazy idea==
 
== 1. sam's crazy idea==
  
*       Split upgrade stesp (in upgrade.php) into separate files or something, with metadata for each step
+
* 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.
+
* 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
+
* 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...
+
* 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
+
* Sam working on this as MDL-58567
  
 
== 3. Scheduled downtime UI ==
 
== 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)
+
* 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 settibgs, just an option to schedule it there. Should have a choice between ending in 'soft' or 'hard' 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 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.
+
* 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 solusion - two verison numbers, 'soft' and 'hard'. Can work basically the same way but the sfot one only does a purge cahces
+
* 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