[05:24:36] TimStarling: I've reproduced the strlen() point you made last week. using https://php.watch/articles/php-dump-opcodes to get a view of it. Interesting indeed how it is reported as a single dedicated opcode as opposed to INIT_FCALL + SEND_VAL [05:24:45] or indeed, worse, INIT_NS_FCALL_BY_NAME if it's under a namespace and not using \strlen() [05:25:11] I did notice that with \strlen, it (correctly) goes all the way to native STRLEN [05:25:29] this was on php8.0 locally. [05:49:26] TimStarling: btw, we do still have wgCentralAuthSessionCacheType and wgMWOAuthSessionCacheType pointed to redis_local which I'd expect to be an issue but have not concretely run into at this point. afaik redis isnt setup to bi-di write and replicate, but maybe it's not as broken as SRE led us to believe? [05:50:00] at worst, that'd be reason to keep non-testwiki rollout to non-session [05:50:45] on paper at least, I believe we currently treat Redis replicating in one direction, and recieing writes only from primary, and during switchover this is flipped. [05:51:02] once sessions are out of it, this would be turned off and both kept dc local [06:07:31] yes those things are still redis_local [06:07:46] why are they redis_local [06:17:10] well, pre-multidc that's convenient for switchovers to not have to change configs given they do replicate in one direction at least afaik. [06:17:12] * Krinkle checks [06:20:00] ok, so yeah, values replicate live in one direction [06:20:16] I vaguely recall there being a one-time operation in volved during the switchover, but it's not the only means of sync at least [06:20:35] ssh mc1038 and mc2020 as per https://github.com/wikimedia/puppet/blob/7eabcbed220b880f17c25c42a49663065d0a6a66/hieradata/common/redis.yaml#L4 [06:20:47] then AUTH with the value found in /etc/redis/tcp_6379.conf [06:21:01] then GET krinkle:test in both, and both nil, then SET to 42 in eqiad, and GET in codfw, finds it [06:21:09] SET in codfw, eqiad remains unchanged [06:22:11] anyway, so I believe you wanted to set up a kask for centralauth sessions [06:24:50] I need to sleep now, but we already know data size is tiny for this, and if the write rate isnt too bad, maybe we could also dump it into mainstash for now. If we do that, though, then we need to also think through the timing of when these writes happen, and whether that is limited to post and loginwiki. We know that's not the case for core sessions, but maybe it is for CA session data? Or else, we do need kask and the write-both latency [06:24:51] or something else (chronologyprotector?) [06:25:31] or even go full circle with memcached :D, but this does need to last several days so maybe not memcached if we want stable sessions. A dedicated memc cluster with a mcrouter-primary write looks pretty attractive now though. [06:26:11] perhaps even for core sessions :P but anyway, politics. [06:26:13] good night [06:31:26] night