tl;dr: it doesn't look like CentralAuth requires any code changes.
MainStash is moving to a SQL cluster, per T212129: Move MainStash out of Redis to a simpler multi-dc aware solution. CentralAuth currently uses the same redis storage as MainStash (redis_local, configured via $wgCentralAuthSessionCacheType for CentralAuth and $wgMainStash for MainStash).
There was talk of decommissioning redis T243520: Decommission the "session redis" cluster. But it now seems that we will retain redis in a dc-local fashion for (at least) ChronologyProtector, per T254634: Determine and implement multi-dc strategy for ChronologyProtector. There's a bit more relevant discussion here
CentralAuth is using storage in 3 distinct ways (this is copied from T254422, with a little editing):
- To store sessions. These are set with a key 'centralauth:session' and TTL_DAY. Important note, the TTL for session data in native sessions we just deployed is 1 hour.
- To briefly transfer data in a secure way between wikis. With CentralAuth, your login request is redirected onto a central wiki, which, upon success, sets a token with a 1 minute TTL, then you're redirected back to your original wiki. It reads the token and transforms it into a local session.
- Additionally, CentralAuth can issue API tokens, which are as well written with a 1 minute TTL. Consuming the token is done via setting a TTL to negative value.
These all use CentralAuthUtils::getSessionStore() . As mentioned above, this points at redis_local via $wgCentralAuthSessionCacheType.
In addition, incidental uses of BagOStuff instances within CentralAuth are:
Maintenance script populateListOfUsersToRename.php, which uses its own HasBagOStuff and doesn't need any changes.
Assuming that redis_local continues to represent an appropriate dc-local redis storage, no changes need to be made to CentralAuth when MainStash moves. If redis_local does change, we would need only a config change, to point $wgCentralAuthSessionCacheType to the appropriate dc-local redis. No change to the actual CentralAuth code would be necessary.
So although we discussed moving CentralAuth to kask in T254422: Move CentralAuth sessions from redis backend to kask, it appears that CentralAuth's needs can be satisfied by the same dc-local redis as ChronologyProtector, for less effort. In short, there appears to be nothing to do here.
If I am incorrect about that, please let me know so that we can make whatever changes are necessary.
(I'm tagging this with a bunch of stuff, for visibility. I'm probably overtagging, so feel free to untag anything not relevant.)