[06:10:06] <marostegui>	 thank you mutante 
[07:01:52] <marostegui>	 jynus: let me know if you have objections for: https://phabricator.wikimedia.org/T399927
[07:02:01] <marostegui>	 I assume it is actually better for the backups speeds
[07:02:04] <marostegui>	 (when you take them)
[08:05:44] <jynus>	 backup speeds for es wouldn't be affected, as we limit concurrency to 2
[08:06:37] <jynus>	 recoveries could be a bit faster, though
[08:08:55] <marostegui>	 jynus: so from your side, it is ok to migrate to 10g?
[08:10:03] <jynus>	 it shoudn't affect me neither good nor badly
[08:10:08] <marostegui>	 ok! thanks
[10:45:42] <federico3>	 marostegui: I'm looking at auto_schema a bit to understand how the downtime works for https://gitlab.wikimedia.org/repos/sre/schema-changes/-/merge_requests/41#note_153314 and it seems we are just letting it expire in future and we do not remove it after the schema change is completed, plus we are not checking for icinga to go green or other health metrics. In theory if the downtime is not long enough we would trigger alarms
[10:51:59] <marostegui>	 Yes, we let it expire. If it's not enough it will page yes, normally I decided based on the size of the table, that's why I asked you to check the biggest tables, so enwiki, commons and wikidata
[10:52:40] <federico3>	 yes I've been looking around and see only the tables in enwiki, the biggest being 3.8 GB
[10:53:38] <marostegui>	 Then you can give it like 4 hours and that's even a loooot but just to be safe 
[10:57:23] <federico3>	 I'm seeing 15 MLN row tops so pretty small. I'm updating the PR
[11:28:09] <marostegui>	 Thanks
[11:28:16] <marostegui>	 I'll check in a bit
[11:35:19] <federico3>	 marostegui: I also opened this WIP https://gitlab.wikimedia.org/repos/data_persistence/dbtools/auto_schema/-/merge_requests/12
[11:38:18] <marostegui>	 federico3: does that wait for icinga to be green?
[11:38:47] <federico3>	 not yet as it's WIP and I wanted to ask Amir's input  (see the TODO comment)
[11:40:21] <marostegui>	 cool
[11:40:35] <marostegui>	 There is no way to add more than one reviewer to a change in gitlab right?
[11:41:20] <federico3>	 nope
[11:43:18] <marostegui>	 :(
[11:51:25] <federico3>	 it's a bit puzzling but it allows only one reviewer 🤷
[12:34:52] <jynus>	 I belive that's one of the important reasons gerrit is not going away
[12:35:14] <jynus>	 maybe it is an enterprise feature or something?
[12:35:26] <jynus>	 (from the non-free version?)
[12:36:24] <marostegui>	 I've always looked for it and never found it, but I thought it was just me being blind
[12:36:31] <marostegui>	 I am a bit shocked, it looks like a very basic feature
[12:38:57] <federico3>	 wow... https://gitlab.com/gitlab-org/gitlab-foss/-/issues/32943
[12:46:15] <marostegui>	 -rw-rw---- 1 mysql mysql   49G Jul 18 11:49 ./sqldata/ruwikinews/categorylinks.ibd 
[12:46:20] <marostegui>	 seriously ruwikinews :O
[15:50:15] <federico3>	 marostegui: your last comment about something to improve is it about a specific line of code or bug? https://gerrit.wikimedia.org/r/c/operations/cookbooks/+/1165546
[16:27:30] <marostegui>	 federico3: about the depool/pool comment 
[16:30:27] <federico3>	 marostegui: ah, I thought I added logging in various places, what do you find missing?
[16:31:11] <marostegui>	 federico3: let's continue on the patch please
[16:31:22] <federico3>	 ok