Background
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
Current State
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:
SpecialCentralAutoLogin::getInlineScript() , for caching of minified javascript. This uses getLocalClusterInstance() and doesn't appear to need any changes.
Maintenance script populateListOfUsersToRename.php, which uses its own HasBagOStuff and doesn't need any changes.
Conclusion
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.)