[03:29:08] <vgutierrez>	 bblack: regarding puppetization per DC with ATS is already feasible with some hiera magic :)
[03:30:14] <vgutierrez>	 bblack: https://github.com/wikimedia/puppet/blob/production/hieradata/common/profile/trafficserver/tls.yaml#L80-L82 is responsible of those certs being deployed
[03:30:50] <vgutierrez>	 bblack: and https://github.com/wikimedia/puppet/blob/production/hieradata/common/profile/trafficserver/tls.yaml#L26-L49 choose the certificates to be used by ATS
[03:31:36] <vgutierrez>	 bblack: so we just need to set those entries per DC as we want and that would do the trick
[03:35:21] <vgutierrez>	 I'm gonna  modify https://gerrit.wikimedia.org/r/c/operations/puppet/+/540470/ to add the ATS bits
[07:49:06] <vgutierrez>	 "X-Connection-Properties": "H2=0; SSR=1; SSL=TLSv1.2; C=ECDHE-ECDSA-AES256-GCM-SHA384; EC=prime256v1;" --> ATS logging the EC on a reused SSL session \o/
[07:49:29] <vgutierrez>	 now I need to provide code good enough to be submitted to upstream... but at least I already got a PoC working
[08:44:09] <gilles>	 FYI there's going to be a DNS track at FOSDEM, we'll share the room with them for our Web Performance track, half a day each
[09:39:12] <vgutierrez>	 them?
[10:33:31] <mark>	 ah cool
[13:41:56] <bblack>	 wish I could be there for it :)
[13:44:13] <bblack>	 vgutierrez: so in https://github.com/wikimedia/puppet/blob/production/hieradata/common/profile/trafficserver/tls.yaml#L26-L49 ... basically if we want per-dc splits with the existing commercials, we need to copy that whole block down to per-dc hiera (or I guess, leave the US sites in common and set the non-US ones separately?)
[13:44:25] <bblack>	 my only concern there is there's so much data to duplicate in that block, aside from vendor choice
[13:45:34] <bblack>	 but maybe we can factor out a separate hieradata there, "base_cert_name" or something like the unified_cert_vendor thing before
[13:45:58] <bblack>	 and then yeah, tangled up in all of this is how we integrate LE, which will have differing paths for all the bits (priv, pub, ocsp)
[13:47:17] <vgutierrez>	 so.. it's just paths and cert monitoring settings
[13:47:36] <vgutierrez>	 and of course the monitoring thresholds need to be different for the LE one
[13:48:30] <bblack>	 I'm just wondering how we abstract it best, mostly
[13:48:47] <vgutierrez>	 but sure.. we could wrap all of that with an enum and just pick between digicert, globalsign or LE
[13:49:11] <bblack>	 ideally we don't duplicate a bunch of data (like the common SAN list), and we have a simple hieradata switch that says succinctly: eqsin is LE, esams is Digicert, US sites are GlobalSign, which is easy to change on the fly in case of incident
[13:49:34] <bblack>	 but then there's the path differences, which will be confusing a bit
[13:49:46] <bblack>	 I guess maybe we can have:
[13:50:33] <bblack>	 1) Some global common hieradata which lists off the cert names and their paths (your enum?): e.g. "unified_cert_options: globalsign: ocsp_path: ... key_path: ... cert_path: ...; letsencrypt: ......"
[13:50:43] <bblack>	 2) Some selector in per-dc hieradata that just picks one of those keys?
[13:52:00] <bblack>	 probably the commercial labels will be date based like before I guess, more like "globalsign-2018: .... ; digicert-2019: ....; letsencrypt: ..."
[13:52:14] <bblack>	 (so that we can swap in cleanly with overlap on the annual commercial renewal)
[13:52:20] <vgutierrez>	 right
[13:52:45] <vgutierrez>	 I'll give it a try (probably on Monday) and run it by you
[13:53:09] <bblack>	 sounds good.  I'll be out all next week, other than maybe sitting in for the big all-tech meeting.
[13:53:18] <vgutierrez>	 I wanna finish some ats hacking tomorrow
[13:53:23] <vgutierrez>	 ack
[13:54:09] <bblack>	 we can't push the new digicert yet anyways, the whole "wait N days for clock skew" thing.  Better late next week or we can just wait for the week after.
[13:55:09] <vgutierrez>	 sure
[13:55:26] <vgutierrez>	 that shouldn't be an issue for ats though
[13:55:49] <vgutierrez>	 just change the tls material paths
[13:56:15] <bblack>	 do we know if it can switch certs with a simple reload or what the impact is, etc?
[13:56:54] <vgutierrez>	 yeah.. currently we reload TLS material every time we refresh the ocsp stapling response
[13:57:03] <vgutierrez>	 no issues so far
[13:57:09] <bblack>	 ok cool
[13:57:12] <vgutierrez>	 replacing the cert itself it's basically the same
[14:32:20] <wikibugs>	 10netops, 10Operations, 10ops-codfw: msw-c1 down? - https://phabricator.wikimedia.org/T234411 (10Papaul) 05Open→03Resolved A was not on site  yesterday when this happen. This morning all same to be good it was maybe the cable so i just made sure that the cable was not loose .
[16:57:04] <wikibugs>	 10Traffic, 10Core Platform Team, 10Operations, 10Performance-Team, and 7 others: RFC: Serve Main Page of Wikimedia wikis from a consistent URL - https://phabricator.wikimedia.org/T120085 (10Jdlrobson) > I've tagged Reading-Web and CPT on the task here for their feedback from product and technical perspecti...
[18:51:45] <wikibugs>	 10Traffic, 10Operations, 10SRE-tools, 10Goal, and 2 others: Automate generation of Management DNS records from Netbox - https://phabricator.wikimedia.org/T233183 (10BBlack)
[19:23:15] <wikibugs>	 10Traffic, 10Core Platform Team, 10Operations, 10Performance-Team, and 7 others: RFC: Serve Main Page of Wikimedia wikis from a consistent URL - https://phabricator.wikimedia.org/T120085 (10Keegan) >>! In T120085#5544560, @Jdlrobson wrote: >> I've tagged Reading-Web and CPT on the task here for their feedb...
[19:32:03] <wikibugs>	 10Traffic, 10Core Platform Team, 10Operations, 10Performance-Team, and 7 others: RFC: Serve Main Page of Wikimedia wikis from a consistent URL - https://phabricator.wikimedia.org/T120085 (10Jdlrobson) Yup.  en.wikipedia.org for desktop (which redirects to mobile en.m.wikipedia.org).
[20:30:07] <wikibugs>	 10Traffic, 10Operations, 10observability: global HTTP (un)availability number, as reported in Frontend Traffic dashboard, is bogus - https://phabricator.wikimedia.org/T234567 (10CDanis)
[20:35:24] <wikibugs>	 10Traffic, 10Operations, 10observability, 10Patch-For-Review: global HTTP (un)availability number, as reported in Frontend Traffic dashboard, is bogus - https://phabricator.wikimedia.org/T234567 (10CDanis)
[20:35:34] <wikibugs>	 10Traffic, 10Operations, 10observability, 10Patch-For-Review: global HTTP (un)availability number, as reported in Frontend Traffic dashboard, is bogus - https://phabricator.wikimedia.org/T234567 (10CDanis) p:05Triage→03Normal
[20:45:25] <wikibugs>	 10Traffic, 10Core Platform Team, 10Operations, 10Parsing-Team, and 8 others: RFC: Serve Main Page of Wikimedia wikis from a consistent URL - https://phabricator.wikimedia.org/T120085 (10Krinkle)
[20:50:44] <wikibugs>	 10Traffic, 10Core Platform Team, 10Editing-team, 10Operations, and 9 others: RFC: Serve Main Page of Wikimedia wikis from a consistent URL - https://phabricator.wikimedia.org/T120085 (10Krinkle) @ssastry, @Esanders  Hi - could you review this RFC for potential impact on Parsoid and VisualEditor?  The curre...
[21:14:13] <wikibugs>	 10Traffic, 10Core Platform Team, 10Editing-team, 10Operations, and 9 others: RFC: Serve Main Page of Wikimedia wikis from a consistent URL - https://phabricator.wikimedia.org/T120085 (10cscott) From Parsoid's perspective:  1) is $wgMainPageIsDomainRoot available in SiteInfo?  Parsoid/JS and the non-integra...
[23:44:19] <wikibugs>	 10Traffic, 10Core Platform Team, 10Editing-team, 10Operations, and 9 others: RFC: Serve Main Page of Wikimedia wikis from a consistent URL - https://phabricator.wikimedia.org/T120085 (10Johan) Something like this for Tech News? (Plus links and clearer handling of URLs.)  The URL of the main page of the Wik...