| Addshore added a comment. |
https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/Wikibase.php#L37-L48
In T197252#4283504, @WMDE-leszek wrote:Some options to overcome the issue (list not complete and not sorted in any way)
- Always run the same version of the software on both systems. Tricky/Maybe even not wanted, as not only means enabling WikibaseLexeme, WikibaseMediaInfo etc on wikiedias, but to get things 100% right, means always having the same version of Wikibase running on both systems. Not doable with the current deployment strategy with deploying Wikibase to different wikis on different days
I do not like this idea.
This means when rolling out new extensions we just have to flip one almighty switch and load it everywhere at once, sounds scary, especially as we will have a rollout like lexeme, but for media info again in the not to distant future.
- Do not share cache prefixes between Repo and Client unless they're the same wiki. Sharing cache between repo and client makes sense in the single-wiki case (e.g. wikidata.org), but is this really needed otherwise? Little bit of random archeology and finding https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/203811/ does not really provide the answer why the shared cache prefix has been introduced.
So the cache key for production is created here: https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/Wikibase.php#L37-L48
It currently only varies on the branch of mediawiki & wikibase that is deployed.
Right now we have some different combinations that this doesn't account for
- Wikibase & No Lexeme
- Wikibase & Lexeme
During the the MediaInfo rollout this will increase again, I'm not sure what the final list of clients for which repos etc will look like or how it will roll out at all.
One important thing to find out here is how much cache space do we actually use?
Is having more keys a viable possibility?
Having different keys based on the deployed wikibase extensions seems feasible to me
- Handle unserialization of unknown classes more "gracefully", using http://php.net/manual/en/var.configuration.php#ini.unserialize-callback-func. We could make said callback throw an exception that Wikibase could handle (e.g. ignore reading from cache in such case). Problem is the setting is global, and could lead to all sort of unforeseen issues.
Pinging @hoo @Amir1 @aude @daniel @ArielGlenn as they might have some clue here, or know some background.
What line in Wikibase actually does this unserialization? perhaps we could change that to something that wouldn't have such a global effect.
Cc: ArielGlenn, daniel, aude, Addshore, Aleksey_WMDE, Pablo-WMDE, hoo, WMDE-leszek, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, Darkdadaah, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
