[09:34:50] <wikibugs>	 10netops, 10Infrastructure-Foundations, 10SRE: Migrate row E/F network aggregation to dedicated Spine switches - https://phabricator.wikimedia.org/T322937 (10cmooney) Just to update in terms of the LVS connections.  After discussing with Brandon I thought it best if the links from all 4 LVS terminate on diff...
[11:57:18] <wikibugs>	 10netops, 10Infrastructure-Foundations, 10SRE, 10Patch-For-Review, 10cloud-services-team (Kanban): Move WMCS servers to 1 NIC - https://phabricator.wikimedia.org/T319184 (10aborrero)
[12:26:03] <wikibugs>	 10netops, 10Infrastructure-Foundations, 10SRE, 10Patch-For-Review, 10cloud-services-team (Kanban): Move WMCS servers to 1 NIC - https://phabricator.wikimedia.org/T319184 (10aborrero)
[15:59:04] <wikibugs>	 10Traffic, 10SRE, 10Patch-For-Review: Upgrade Traffic hosts to bullseye - https://phabricator.wikimedia.org/T321309 (10ssingh)
[17:06:17] <wikibugs>	 10Traffic, 10SRE, 10Patch-For-Review: ATS should alert if the number of total or active connections reached maximum - https://phabricator.wikimedia.org/T292815 (10BCornwall) @Vgutierrez, while this doesn't have strict support for multiple ATS instances, bblack suggested that by simplifying all this it would...
[17:20:03] <claime>	 Hey :) The grace period for apple-search decom is ending tomorrow, hence the CR batch v.guttierez b.black. It doesn´t necessarily need to be done tomorrow, even if I´d like to, but I got a bit behind on creating the patches, and will probably need some level of hand holding at the time of deployment
[17:20:54] <claime>	 ^^ Relevant task https://phabricator.wikimedia.org/T316296
[17:21:06] <vgutierrez>	 that typo just hurts
[17:21:25] <claime>	 Oh I'm so sorry
[17:21:30] <vgutierrez>	 ;P
[17:21:38] <claime>	 I didn't tab complete and add the . and went full on bad spanish
[17:21:44] <claime>	 <3
[17:22:03] <vgutierrez>	 you can fix it with some Belgian beer
[17:22:07] <vgutierrez>	 I'd say French.. but you know
[17:22:34] <vgutierrez>	 ;P
[17:22:35] * claime takes the deserved humiliation stoically
[17:22:43] <claime>	 :P
[17:23:12] <claime>	 On the plus side, I'm sure it won't ping you if I write your name like this.
[17:23:21] <vgutierrez>	 that's right
[17:23:36] <vgutierrez>	 but you flooded my inbox with gerrit mails and wrote on -traffic
[17:23:41] <vgutierrez>	 so that did it ;P
[17:23:52] <vgutierrez>	 I'll take a look
[17:24:29] <claime>	 I really didn't want to cause a context switch, it was some explanatory context that probably should have been in the task
[17:30:48] <vgutierrez>	 claime: BTW, did you miss hieradata/common/profile/kubernetes/deployment_server.yaml :?
[17:31:04] <vgutierrez>	 or that's on a CR that I'm not seeing?
[17:31:50] <claime>	 vgutierrez: in what key? if it's profile::kubernetes::deployment_server::services that's afterwards
[17:32:42] <claime>	 https://wikitech.wikimedia.org/wiki/Kubernetes/Remove_a_service
[17:32:50] <claime>	 (Wrote the doc when I rename mwdebug)
[17:34:30] <vgutierrez>	 yup
[17:34:36] <claime>	 vgutierrez: DNS should be merged after switching to lvs_setup? I followed https://wikitech.wikimedia.org/wiki/LVS#Remove_a_load_balanced_service 
[17:35:23] <vgutierrez>	 so.. IIRC if you remove the DNS record before downgrading from production to lvs_setup that would trigger a puppet failure on lvs boxes
[17:37:48] <vgutierrez>	 culprit being wmflib/functions/service/get_services_for.pp
[17:38:34] <claime>	 Ok, adding dependency :)
[17:39:32] <vgutierrez>	 hmmm or not
[17:44:24] <claime>	 it doesn't seem to do lookups
[17:47:48] <vgutierrez>	 nah, the dependency is with the discovery stanza on service.yaml
[17:47:48] <vgutierrez>	 my fault
[17:48:14] <claime>	 np, I'll remove the dependency then