[09:40:29] <dcausse>	 errand
[10:37:31] <pfischer>	 lunch
[11:15:47] <dcausse>	 lunch
[13:07:32] <ebernhardson>	 \o
[13:08:26] <dcausse>	 o/
[13:30:40] <ebernhardson>	 can't quite decide, what is the right setup for cirrus jobs and redirect docs?  A redirect needs two updates, source and target.  The "cirrus way" is probably a job for each one, but seems wasteful. 
[13:31:44] <dcausse>	 hm for the streaming update I'd just ship two updates from the producer, for cirrus jobqueue approach not clear...
[13:32:54] <ebernhardson>	 yea i haven't even gotten into the streaming updater too deeply yet, going to be interesting..for cirrus i have an UpdateRedirectDocument job along with a new Updater::updateRedirectDocument method that skips tracing redirects
[13:33:08] <ebernhardson>	 i suppose can leave it, it's just feeling like extra indirection
[13:36:16] <dcausse>	 I'd need to read the code again... does not seem too bad to have 2 jobs? one for the redirect and one for updating the target, not sure where I see the indirection?
[13:36:50] <ebernhardson>	 well, Updater::updateFromTitle already has to trace redirects anyways, to know which doc to update. It could probably do both
[13:38:02] <ebernhardson>	 but instead, at least for now, i have three spots in ChangeListener that inject the redirect job
[13:39:03] <dcausse>	 ah I see, you detect the redirect early
[13:56:24] <ebernhardson>	 hmm, naming is also hard...we have withredirects: for search,  but i didn't know what to call the api param on prop=cirrusdoc.  Calling it withredirects seemed a little awkward so i called it redirectscope (the internal flag name)...but now it has two external names :P
[13:57:08] <ebernhardson>	 it's needed for some minimal api testing
[14:00:50] <dcausse>	 oh right... could easily be confusing :/
[14:01:16] <dcausse>	 from translate: [/ttmserver-test/_mapping] contains unrecognized parameter: [include_type_name]
[14:02:07] <ebernhardson>	 sigh, hopefully it's not too hard to fix.  But yea no more index-types :S
[14:03:49] <dcausse>	 is that some BC logic you could add but can't remember what version
[14:04:18] <dcausse>	 i.e. is it fine to drop that BC support if translatewiki.net is still running elasticsearch 7
[14:04:20] <dcausse>	 ?
[14:04:50] <ebernhardson>	 i would have to double check, i'm pretty sure in 7 the only valid value was _doc, but i'm not sure if it was optional everywhere
[14:05:03] <ebernhardson>	 i feel like it should be, but don't remember
[14:05:27] <ebernhardson>	 or more to say, i have an awkard feeling that we had seen some places that didn't take it :S
[14:05:37] <ebernhardson>	 didn't allow removing it i mean
[14:06:57] <dcausse>	 trying to search for when we removed include_type_name
[14:20:03] <dcausse>	 removed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CirrusSearch/+/837700 so should work fine without with elasticsearch 7
[14:23:49] <ebernhardson>	 yea, does suggest it should be ok
[14:24:30] <ebernhardson>	 I'm tempted to re-use the alt-language wikis to have different combinations of redirects enabled,  build/use gives 4 possible combinations, although only 3 should be tested.
[14:24:37] <ebernhardson>	 but it seems annoying to remember as wel
[14:27:08] <dcausse>	 you mean in the integration tests?
[14:27:40] <ebernhardson>	 yea, for things like verifying cirrus index-writes are all writing the right things and deleting the right things after various edit actions
[14:28:22] <ebernhardson>	 or maybe just plan that build=>true, use=>true will eventually be the default, and go in that direction
[14:28:23] <dcausse>	 haven't thought about that but yes the transition might take time and proper testing of the intermediate states is going to be helpful
[14:29:00] <dcausse>	 build=>true by default in the tests perhaps?
[14:29:09] <dcausse>	 so you test only 2 modes?
[14:29:23] <ebernhardson>	 hmm, yea that would at least simplify it a bit
[14:34:58] <dcausse>	 trying yet another approach with cindy, without the create page tests it's around 17min for the second opensearch to test I'm switching just the opensearch image and not re-create the full env, it also runs UpdateSearchIndexConfig+ForceSearchIndex in parallel (takes ~30s to switch)
[14:35:14] <dcausse>	 and I'm secretely hoping that docs already in the index might speed things up
[14:36:13] <dcausse>	 downside is that it's no longer isolated between the two runs IIRC the test suite used to work on an existing db
[14:45:11] <ebernhardson>	 i think the pre-loaded docs do speed things up, i often don't reset the environment when i run them locally.  
[16:56:20] <ebernhardson>	 oh, realizing because i didn't reset the environemnt, 24m vs 8m wasn't completely fair.  Lemme try again with a reset env...
[16:58:49] <ebernhardson>	 also remembering i tried to parallelize wiki creation in the past, but it turned out mwcli wasn't race-safe against parallel execution
[17:08:51] <ebernhardson>	 well, i was in a different meet, but it ran in 7:49 this time, so maybe 8m is fair