[08:37:10] <kormat>	 sobanski: aw. i liked to think that "decommission <FQDN of server>" meant that DCops could just select a server of their choice to decom
[08:37:33] <Emperor>	 kormat: Maximum Deletion!
[08:38:01] <sobanski>	 The YOLO decommissioning paradigm
[08:38:10] <Emperor>	 (we had a cyberman slack emoji at old-work for just such things)
[08:38:28] <kormat>	 Emperor: :D
[08:38:45] <sobanski>	 I had to look up cyberman... not a Doctor Who person
[08:39:07] <jynus>	 sobanski, how do they decom servers in California?
[08:39:30] <sobanski>	 jynus: this will never stop being an amazing fact :)
[08:39:49] <sobanski>	 Also, probably in a chill way, maybe at the beach?
[08:42:26] <jynus>	 sobanski, did you see: https://phabricator.wikimedia.org/T262668#7288778
[08:43:38] <sobanski>	 Looking good!
[10:07:36] <kormat>	 marostegui: do you think 1 week notice is enough for an s7 switch? thinking about scheduling for next wednesday morning
[10:08:09] <marostegui>	 I think that should be fine yeah
[10:23:03] <kormat>	 marostegui: https://phabricator.wikimedia.org/P17043
[10:23:28] <marostegui>	 oooooooooooh!!!!! <3<3
[10:23:31] * marostegui bookmarks that
[10:24:01] <kormat>	 it's very crude, but useful
[10:30:35] <Emperor>	 we need somewhere to store these snippets
[10:35:40] <kormat>	 Emperor: operations/software - dbtools is probably the 'natural' place
[10:35:45] <kormat>	 at least for this one
[11:00:46] <kormat>	 30 updates later, it's getting closer to something which works
[12:20:54] <kormat>	 marostegui: (non-urgent) can i get you to review https://phabricator.wikimedia.org/T289129 please?
[12:21:18] <marostegui>	 yep!
[12:27:00] <kormat>	 cal invite sent out
[12:49:48] <kormat>	 jynus: fyi, i'm going to be (slowly) working on replacing wmfmariadbpy over the next eon or two, hopefully starting this quarter. just wanted to give you a heads-up so you're not taken by surprise.
[12:51:43] <kormat>	 jynus: we can leave RemoteExecution in wmfmariadbpy for use by transferpy/wmfbackups
[12:51:54] <kormat>	 the replacement won't need it
[13:04:14] <jynus>	 I have a few dependencies, remoteExecution and the port section thingy
[13:05:54] <kormat>	 oh yeah, good point re: port-section
[13:06:26] <kormat>	 alright, made a note of that
[13:07:00] <jynus>	 may I ask about your general plans? if it a mere rewrite I won't be too affected, but if you are going to change package names and apis I would have to rewrite my code too
[13:10:17] <jynus>	 e.g. big arch changes (where endpoints are) or new languages introduced
[13:10:29] <kormat>	 endpoints? i'm not sure what that means in this context
[13:10:38] <jynus>	 as in, will you use cumin?
[13:10:47] <kormat>	 for the new db-switchover, yes
[13:10:56] <kormat>	 no new languages, it'll be python
[13:11:02] <jynus>	 with the same things expected on cumin* hosts be there still?
[13:11:18] <kormat>	 i guess? i'm not sure what you're referring to
[13:11:19] <jynus>	 e.g. the port section files
[13:11:24] <kormat>	 right, yes.
[13:11:38] <jynus>	 those are the thing that would affect backups logic
[13:11:58] <kormat>	 they follow from the port-section mapping part of the lib
[13:12:01] <jynus>	 e.g. I run backups from cumin because I expect the section-port api to be tehre
[13:12:11] <kormat>	 ahh i see. so from that perspective, no, no big arch changes.
[13:12:26] <jynus>	 ok, that makes me not worried :-)
[13:13:17] <jynus>	 just keep me up to date when doing changes, specially to those 2 things
[13:13:30] <kormat>	 will do 👍
[13:13:53] <jynus>	 so I can prepare changes to code on my side in advance, and I don't block you 0:-)
[13:14:31] <jynus>	 the other thing I can see afecting me is if package names change, to update my package dependencies
[13:14:47] <jynus>	 thanks for the heads up, it is super-useful to me!
[14:14:30] <kormat>	 marostegui: orchestrator grants are missing for s3 sanitarium + wikireplicas. fixing.
[14:15:23] <marostegui>	 mmm I see them there
[14:15:30] <marostegui>	 (the hosts in orchestrator I mean)
[14:16:27] <kormat>	 `ReadTopologyInstance(db1154.eqiad.wmnet:3313) ReplicationLagQuery: Error 1142: SELECT command denied to user 'orchestrator'@'208.80.155.103' for table 'heartbeat'`
[14:16:44] <kormat>	 marostegui: i'm guessing the user existed, but not the grant for the hb table. not sure.
[14:16:45] <marostegui>	 Ah, so maybe the discovery grant was there but not the one to detect lag!
[14:16:47] <marostegui>	 yeah
[14:16:49] <marostegui>	 that could be
[14:17:01] <marostegui>	 Thanks for fixing it - going offline now till Tuesday! :*
[14:17:06] <kormat>	 :D
[14:17:08] <kormat>	 o7