Page MenuHomeMiraheze

Introduce ability to deploy multiple mediawiki versions to 1 server
Closed, DeclinedPublic

Description

This would allow us to:

  • Reduce the actual impact of 1.x - 1.x+1 upgrades to mere seconds
  • Allow current experimental wikis to get upgrades early so we can be more confident that impact is minimal

Downsides:

  • Adds an extra step to deploying mediawiki upgrades.
  • Uses more disk space (probably about 3GB per server)

Event Timeline

RhinosF1 created this task.

I thought about this also, with the addition of experimental yesterday. But I also considered something else, the changes in SQL. This would require experimental wikis to have different SQL, which would be kinda difficult. We'd also have to either add something to ManageWiki to allow experimental wikis to have different SQL paths in ManageWikiExtensions, or have a new mw-config branch.

In regards to software updates (not things behind a feature flag), I'd expect them never to get it more than a few days early. For 1.X upgrades, a matter of hours.

So I think SQL wise it would be manageable but we can always simply set it to use the right folder based on whether a wiki is experimental or not. I assume we can ensure $IP will still work so it would only be wikis switched during the short time.

I'd expect them to use the same config branch based on my plan fwiw.

Universal_Omega closed this task as Declined.EditedMon, Sep 26, 05:38
Universal_Omega claimed this task.

After some discussion with @Reception123, we have decided to decline this task for now.

  • This is currently not necessary, as our current upgrade flow has worked for us for years, granted it has had some issues occur in the past. However, this last upgrade had almost no issues occur during upgrade, and went smoothly enough, this task would likely not provide a significant benefit for the intention of easing the upgrade flow.
  • Doing this would likely require quite a bit of additional disk space on MediaWiki servers, that currently investing in soley for this purpose seems like a waste of resources, and currently not necessary to do at this time.

This could be reconsidered eventually, but for the time being, this is declined, due to it having no visible benefit, and no current intention at implementation.