In order to experiment with different methods for building and integrating l10n caches in a containerized world, we'll need to know what the current compilation process looks like in terms of process and computation.
|Open||None||T198901 Migrate production services to kubernetes using the pipeline|
|Open||None||T238770 Deploy MediaWiki to Wikimedia production in containers|
|Resolved||dancy||T260827 l10n process for MW containerization|
|Resolved||dduvall||T261360 Get scap-vagrant working for use in l10n tracing|
|Resolved||dancy||T268698 Add flag to rebuildLocalisationCache.php to skip MessageBlobStore::clearGlobalCacheEntry|
|Resolved||dancy||T238436 Allow running mergeMessageFileList (or any other maintenance script) without needing a DB connection|
|Resolved||dancy||T237148 Allow running rebuildLocalizationCache with Gadgets extension loaded and no DB connection|
My notes after tracing the process:
Why is this done during LC rebuild? LC is built upon the first scap sync of
test wikis on Tuesdays long before update-wikiversions has been performed.
- What benefit is there to clearing the message blob store cache at this point?
- Is it in fact a race condition regardless of when it's cleared? Wouldn't new requests result in re-cached messages from the previous version of MW before the new version is promoted via sync-wikiversions?
- The cache is cleared again by scap explicitly following a sync-wikiversions so this really seems redundant.
The order is which l10n sources for each language are processed determines the
aggregate messages produced. Use of an array concatenation operation
(aggregate_messages + source_messages) means that entries (by key) in each
source_messages that already exist in aggregate_messages will be ignored.
There are two hooks run during this process,
LocalisationCacheRecacheFallback and LocalisationCacheRecache. Neither
appear to have be used significantly by existing extensions.
@tstarling can you provide insight into why the MessageBlobStore is cleared during this process and whether we might be able to remove/decouple it from localization rebuilds? (See above questions/comments.)
For more context, my motivation here to see what parts of localization precaching can be done in a containerized MediaWiki build pipeline (see T259817#6395133) and how far upstream. Before/after all extensions/skins/vendor are integrated? Do we absolutely need all prod configuration or only a list of enabled exts? Do we need to allow extensions to modify messages during compilation or can we deprecate those hooks? (To the latter, it seems like they aren't used in any prod-enabled extension.)
Thanks for taking a look, @tstarling. It looks like there's more context for the MBS cache clear in T222539: Scap deployments are not purging MessageBlobStore (was: Stale localized messages) and the related patchset to scap as well.
I'm handing this task off to @dancy as he's expressed interest in tackling l10n issues related to current deployments and containerization.
Just to summarize my current understanding and seek clarification for the handoff, @Catrope, it seems from your comments in that task and associated commit message that performing the MBS cache clear in LocalisationCache::recache is not correct because recaching is performed on the deployment host long before a sync—i.e. there is a race condition between new production requests and a sync or group promotion. Is that accurate? And is it accurate to say that it should instead be performed in the following two cases?
- Whenever LC files are rebuilt and synced for a currently deployed release. Seems like your patch already addresses this.
- Whenever a release is promoted (following sync-wikiversions). It's not clear to me whether this is already the case as a result of that patchset.
And finally, can we remove the MBS cache clear from LocalisationCache::recache?
Thanks for taking this on, @dancy.