Page MenuHomePhabricator

Investigate/trace rebuildLocalisationCache process for MW containerization
Open, MediumPublic

Description

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.

Event Timeline

dduvall created this task.Aug 19 2020, 5:11 PM
dduvall claimed this task.Aug 19 2020, 5:13 PM
dduvall triaged this task as Medium priority.
dduvall renamed this task from Profile l10n cache compilation to Investigate/trace rebuildLocalisationCache process for MW containerization.Aug 31 2020, 5:13 PM
dduvall added a comment.EditedSep 24 2020, 8:39 PM

My notes after tracing the process:

MessageBlobStore clear

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.

Merge order

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.

Hooks

There are two hooks run during this process,
LocalisationCacheRecacheFallback and LocalisationCacheRecache. Neither
appear to have be used significantly by existing extensions.[1][2]

[1]: https://codesearch.wmcloud.org/search/?q=LocalisationCacheRecacheFallback&i=nope&files=&repos=
[2]: https://codesearch.wmcloud.org/search/?q=LocalisationCacheRecache&i=nope&files=&repos=

@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.)

MessageBlobStore was @Catrope's work, he added this feature to rebuildLocalisationCache in 2010, so he can probably explain better than I can.

dduvall reassigned this task from dduvall to dancy.EditedOct 1 2020, 7:21 PM
dduvall added a subscriber: dancy.

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?

  1. Whenever LC files are rebuilt and synced for a currently deployed release. Seems like your patch already addresses this.
  2. 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.

dancy added a comment.Oct 16 2020, 6:03 PM

Talked to @Catrope yesterday and he confirmed that the early MBS cache clear is unnecessary.