[07:37:40] 10netops, 10Data-Engineering, 10Infrastructure-Foundations, 10Product-Analytics, and 2 others: Maybe restrict domains accessible by webproxy - https://phabricator.wikimedia.org/T300977 (10Joe) >> **First**: How difficult & how much overhead would it be to make the proxy redirect requests made to internal d... [09:08:27] XioNoX, topranks: I've a question wrt homer and the new lsw*. Should we exclude them from the daily report for now? They are always in error and I'm afraid we might get used to ignore the report and this will hide other diffs [09:09:25] volans: ideally the devices with staged status shouldn't show up in te daily diff [09:10:49] meaning that they are supposed to work? [09:10:53] ah sorry shouldn't [09:11:41] the config has Active, Staged as device_statuses for the inventory [09:12:02] but I guess we want to keep that to be able to run home ron them [09:12:42] yeah exactly [09:12:56] so we would need to have a different config file for the daily diff [09:19:24] we could add the the status into the metadata we inject and then do: homer 'status:active' diff [09:19:27] in the daily diff [09:19:55] it's a 5 minutes patch I think [09:21:20] GTT issue in drmrs is solved [09:31:51] +1 to the change in Homer diff behaviour based on device status (sry for the noise btw) [09:34:33] Great news about GTT! [09:36:32] no worries for the noise, not your fault, we have to setup things before they're ready :) [09:43:20] sent https://gerrit.wikimedia.org/r/c/operations/software/homer/+/762774 [11:32:45] topranks, XioNoX: I have made a new homer release (0.4.0), let me know when it's a good time for me to deploy it that doesn't interfere with your work [11:33:47] volans: good to go any time, I'm not using it right now (or using from my laptop) [11:34:08] volans: +1 [11:36:20] ack, proceeding then [11:57:48] 10netops, 10Infrastructure-Foundations, 10SRE, 10Traffic, 10Patch-For-Review: Enable IPv6 for Wikidough - https://phabricator.wikimedia.org/T301165 (10cmooney) @ssingh I haven't had time to go through all of this and work it out, but some things seem clear enough. As per @Majavah's comments on the CR, i... [12:16:36] 10netops, 10Infrastructure-Foundations, 10SRE, 10Traffic, 10Patch-For-Review: Enable IPv6 for Wikidough - https://phabricator.wikimedia.org/T301165 (10ayounsi) Puppet will automatically filter v4 from b6 neighbors and should do the right thing when v4 and v6 IPs are mixed in `neighbors_list` https://git... [12:55:38] INFO:homer.devices:Matched 43 device(s) for query 'status:active' [12:55:41] yay [12:55:44] yay [13:08:07] 10netops, 10Infrastructure-Foundations, 10SRE, 10Traffic, 10Patch-For-Review: Enable IPv6 for Wikidough - https://phabricator.wikimedia.org/T301165 (10cmooney) Thanks @ayounsi makes sense. I wonder what will happen in this case, with the input being two IPv4 addresses? Will it interpret neighbors_list... [13:08:24] I've also sent the puppet patch to change the daily diff [13:17:07] volans: awesome! nice work. [13:17:39] btw there is a diff for elukey's ssh key on the mr1 [13:25:52] thus proving we definitely needed this! [13:40:16] topranks: are any of you taking care of those? should I ask luca to do it? or do it myself [13:40:34] don'\t want to create issues if there is any pending work [13:40:55] I can do it [13:41:27] let me look at the diff, I wanted to check with XioNoX if there was anything to consider with the mr device, but I'm sure it's fine [13:44:21] ack, thanks a lot, no hurry [13:44:28] what's the up with the mr? [13:44:30] the timeouts? [13:44:33] Yeah just working through them see a few alright. [13:44:58] XioNoX: Nothing, not actually sure which one, just making sure you aren't working on it? [13:45:44] I think just an SSH key change is outstanding on it [13:45:49] cool [13:45:51] which I'm sure can go through [13:46:14] for the management routers' timeouts I'm waiting to have them all replaced by SRX300 first [13:46:37] yeah, and move the SSH port also is that related? [13:46:52] yeah exactly [13:48:36] 10netops, 10Data-Engineering, 10Infrastructure-Foundations, 10Product-Analytics, and 2 others: Maybe restrict domains accessible by webproxy - https://phabricator.wikimedia.org/T300977 (10Ottomata) @Joe I think most of the usages of webproxy that folks here are concerned with aren't by production services.... [14:04:12] 10netops, 10Data-Engineering, 10Infrastructure-Foundations, 10Product-Analytics, and 2 others: Maybe restrict domains accessible by webproxy - https://phabricator.wikimedia.org/T300977 (10akosiaris) >>! In T300977#7710861, @Ottomata wrote: > @Joe I think most of the usages of webproxy that folks here are c... [14:05:31] topranks: thank you for all the code reviews and patches; I will get to them after the meetings [14:07:33] no probs! [14:23:57] 10netops, 10Discovery, 10Infrastructure-Foundations, 10SRE: Speed up network connections for Elastic hosts - https://phabricator.wikimedia.org/T301577 (10bking) Hello Cathal, Ryan and I are in training this week, but I would love to meet with you (maybe next week) and talk specifics about network (or any... [14:38:24] 10netops, 10Infrastructure-Foundations, 10SRE, 10Traffic, 10Patch-For-Review: Enable IPv6 for Wikidough - https://phabricator.wikimedia.org/T301165 (10ssingh) >>! In T301165#7710616, @ayounsi wrote: > Puppet will automatically filter v4 from v6 neighbors and should do the right thing when v4 and v6 IPs a... [14:49:03] 10netops, 10Infrastructure-Foundations, 10SRE, 10Traffic, 10Patch-For-Review: Enable IPv6 for Wikidough - https://phabricator.wikimedia.org/T301165 (10cmooney) > Do we anticipate other for uses of the anycast service? I don't think we would rule out introducing new services based on it, but right now I... [15:32:37] 10netops, 10Discovery, 10Infrastructure-Foundations, 10SRE: Speed up network connections for Elastic hosts - https://phabricator.wikimedia.org/T301577 (10cmooney) Thanks Brian > Ryan and I are in training this week, but I would love to meet with you (maybe next week) and talk specifics about network (or a... [20:18:54] FYI netbox pre-release v3.2-beta1 is out, with tons of features [20:24:56] volans: ohhh [20:25:17] upgrade is going to be quite the journey [20:39:48] yeah, unfortunately [20:49:47] volans: btw, re: Etherpad and IPV6, I just wanted to explain what went wrong _before_ I got to fix it and which options I had. Then listening on "::" was the fix. One part I wrote was incorrect though. That is not IPv6-only. It's both, v4 and v6, but only on Linux. It wouldn't be on BSD or something. [20:50:08] and then we also use that for gitlab now [20:50:48] so no worries, NOT planning to have any special cases. ALL IPv6 enabled [20:52:00] though.. the part that envoy does not fall back transparently to v4 if v6 fails.. is still open.. that was not the expected behaviour [20:55:03] mutante: got it, yes what throw me off was that :: might listen on both or only v6 and AFAIUI it's implementation dependent [20:55:41] volans: exactly, I thought it would be only v6, but as confirmed by Alex it is BOTH. But only on Linux [20:55:45] I wonder for those software that listen on both v4/6 what's the way to make them listen only on v6 if one day we would want to go there [20:55:55] ::1 maybe [20:56:20] that's localhost though :D [20:56:24] and there is a way to turn that feature off [20:56:45] well, that would work for this setup where something is behind envoy on localhost [20:56:54] there is some sysctl to turn that stuff off [20:56:59] the "auto dual stack" thing [20:56:59] ack [20:57:47] anyway, my only concern was that as long as we have both A and AAAA we should make sure that we listen on both, just that :) [20:57:52] thanks for the clarification [20:58:47] yep, that's what happened. the part that threw me off was .. we did NOT have AAAA for the previous etherpad server (1002) but then we did with 1003