[05:36:29] 10Traffic, 10SRE-OnFire, 10conftool, 10serviceops, and 2 others: Pybal maintenances break safe-service-restart.py (and thus prevent scap deploys of mediawiki) - https://phabricator.wikimedia.org/T334703 (10Joe) 05Open→03Resolved AIUI this is now resolved [08:46:30] 10Traffic: Allow purged to specify buffer lenght - https://phabricator.wikimedia.org/T346874 (10Fabfur) [09:09:04] 10Traffic, 10Patch-For-Review: Allow purged to specify buffer length - https://phabricator.wikimedia.org/T346874 (10Vgutierrez) [09:10:26] ^^ tnx for the typo correction [09:12:09] 10Traffic, 10SRE: Varnish mobile redirection misses some sites - https://phabricator.wikimedia.org/T344175 (10Fabfur) Hi @nshahquinn-wmf , changes to the first batch of domains (https://gerrit.wikimedia.org/r/c/operations/puppet/+/957292) should be applied during the next 30'. If you notice something strange p... [10:25:57] 10netops, 10Infrastructure-Foundations, 10SRE, 10Epic: [tracking] Don't keep on the public vlans hosts that don't require it - https://phabricator.wikimedia.org/T317177 (10aborrero) [10:26:30] 10netops, 10Cloud-VPS, 10Infrastructure-Foundations, 10SRE, and 3 others: Move cloud vps ns-recursor IPs to host/row-independent addressing - https://phabricator.wikimedia.org/T307357 (10aborrero) 05Open→03Resolved a:03aborrero [13:17:02] Hi folks! [13:18:06] hi [13:18:15] the ML team needs to point ores.wikimedia.org to ores-legacy.wikimedia.org. Initially I thought to use DNS, but after a chat with the team we re-thought the solution since both use dyna.wikimedia.org (are CNAMEs of it) [13:18:53] so in theory we'd need a HTTP redirect, to make things in the right way (namely clients connecting to ores-legacy.w.o) [13:19:19] IIRC we do have some service that does it, would it be a good use case for us? Or should we find a different solution? [13:19:49] (or maybe I am totally off and something else is needed, I smell a pebcak) [13:21:10] is there a context ticket? [13:29:36] mw related redirects for canonical domains are usually handed by the mw layer itself via redirects.dat [13:29:58] ncredir isn't an option cause it doesn't handle canonical domains traffic [13:32:22] elukey: I guess what I'm trying to understand is: is there a new ores that's reusing the old ores.wm.o hostname? or is this just a rename to make the legacyness more visible in the URI, or? [13:34:37] bblack: o/ so ores-legacy.wikimedia.org is a k8s-backed API that offers almost the same API as ores.w.o, but it calls Lift Wing behind the scenes. We'd like to move all clients that have hardcoded ores.w.o to it basically [13:34:48] to drain traffic and finally deprecate the bare metal ores nodes [13:34:59] ores-legacy has also some info in the UI related to the deprecation etc.. [13:35:15] so we'd love people hitting ores.w.o from a browser to see that UI instead [13:35:37] for some reason naively thought to use DNS but of course it is more complicated [13:35:48] vgutierrez: ack thanks! [13:37:08] elukey: given that you manage both ores and ores-legacy isn't an option to perform the 302 in ores.wm.o itself? [13:38:08] vgutierrez: in theory yes, in practice touching ores's code is not a fun experience :D [13:41:56] elukey: so, the desired redirect I guess is only for the root of the domain? but callers accessing ores.wm.o/foo/bar should keep using the "real" ores directly from there? [13:43:31] if I'm hearing you right, the desired outcome is basically that "ores" is still the old ores, and "ores-legacy" is the new replacement that utilizes Lift Wing (but I guess it is also just a transitional thing to using some other lift wing interface?) [13:44:13] or was the desire to redirect /all/ traffic from ores->ores-legacy? [13:44:13] bblack: good point, we aim to move all the traffic to ores-legacy, not only root [13:44:35] ok [13:45:22] so why are we renaming the canonical name at all? couldn't you just switch ores.wm.o to directly access the new Lift Wing -based thing? [13:46:30] bblack: do you mean via ATS config? Changing the discovery backend I mean [13:46:36] or do you mean in another way? [13:46:52] I'm just speaking in the abstract about the service users are consuming, not the implementation [13:47:26] in other words: what's the point of making a transition to the new hostname ores-legacy.wm.o, if they were already accessing ores.wm.o and that whole domain just redirects to ores-legacy. [13:47:29] okok, yes in theory we could. One thing that I liked about the (wrong) DNS idea was that we could have rolled it back easily [13:48:33] bblack: I guess that among the pros there was an explicit redirect etc.., so it was more clear what was happening, but not really important [13:49:31] if we just changed the routing (ATS routing for ores.wm.o) from one internal discovery backend to another, that's rollback-able as well. [13:49:45] yep yep definitely [13:49:59] anyways, it's up to you, we can implement whatever. [13:50:08] (at some layer!) [13:50:21] nono I wrote in here to get feedback from you folks :) [13:50:30] switching the ATS backend may be the quickest option [13:51:03] * elukey listens to Valentin whispering "you need to check your backend TLS certificate first" [13:51:12] ahhahah [13:51:26] openssl s_client is your friend :) [13:51:46] if you ask vgutierrez how he is doing, he will give you an openssl s_client command for it [13:51:52] I will surprise you, the SAN is already there IIRC [13:51:59] elukey: lovely :D [13:52:01] sukhe: lol [13:53:51] thanks all!