[00:03:06] Reedy: I don't think there specific special cases for those [00:11:01] hmm. do we just do it for all special pages? [00:11:09] I guess as we do for Special:Version we do.. [00:14:34] well I mean, we set no-cache headers on almost all outputs by default [00:30:29] hey traffic, as part of https://phabricator.wikimedia.org/T266470 the search team wants to expose our test instance `wdqs1009` to the public internet [00:30:54] this is a test server to expose upcoming changes in WDQS to users so that they can validate that their tools still work, and we manage the server the same as our other production instances so we don't foresee any security issues [00:31:58] do you guys have any concerns and/or any input on the best way to do that? naively I'd think we need a single public IP, a DNS entry like `query-test.wikidata.org`, and whatever configuration of the caching/routing layer is necessary [00:33:57] oh and lastly the instance would be exposed for a limited time (months) before going back to it just being an internal server again (at which point we can give back the IP) [00:42:58] I guess you probably don't need a seperate IP [00:43:22] query.wikidata.org and www.wikidata.org both go to dyna.wikimedia.org on the same IP etc [00:43:34] so it's just the glue in between to get it to the right place [01:28:09] But without a public IP address `wdqs1009.eqiad.wmnet` wouldn't be externally reachable, right? (Note the test instances aren't behind LVS or anything like that) [01:28:20] * ryankemper is admittedly very bad at this stuff :P [01:33:12] Not directly, no... But presumably you shouldn't need it to be [01:33:29] most of the public site stuff resolves to dyna.wikimedia.org and IIRC, that's LVS ("the glue") that gets it to the right server underneath etc [01:52:03] Ah, so I imagine in this case I'd be treating it much like any other service and adding a new entry to the `service::catalog`? [01:52:21] (cc gehel for your irc backlog ^) [03:19:04] 10Traffic, 10SRE, 10Wikimedia-Logstash, 10observability, and 3 others: Changing Kibana filters is ridiculously slow - https://phabricator.wikimedia.org/T189333 (10Krinkle) a:05Krinkle→03None [03:19:30] 10Traffic, 10SRE, 10Wikimedia-Logstash, 10observability, and 3 others: Changing Kibana filters is ridiculously slow - https://phabricator.wikimedia.org/T189333 (10Krinkle) 05Open→03Resolved a:03Krinkle [09:53:11] vgutierrez: o/ [09:53:17] thanks a ton for https://gerrit.wikimedia.org/r/c/operations/puppet/+/657296 [09:53:27] I have a question for you from my team [09:53:42] they asked, if possible, to add this info and another one that the serviceops team needs to X-Analytics [09:54:19] namely https://phabricator.wikimedia.org/T271953#6758654 [09:54:19] that looks like a click bait link [09:54:34] let's see.. ;P [09:54:56] :) [09:55:33] that looks more like varnishland than ats-tls [09:55:42] ^^ ema O:) [09:56:13] vgutierrez: ah ok so X-Analytics is not touched by ats-tls, but populated later on right? [09:56:30] I always confuse who does what [09:56:53] ats-tls provides X-Analytics-TLS' [09:57:01] ahhh right of course [09:57:21] and also enforces that X-Analytics doesn't reach the users [09:57:37] but X-Analytics content is populated by varnish [09:57:49] perfect, +1ed the change [09:58:00] <3 [10:17:39] elukey: I see a meeting (which I cannot attend due to time conflict with kindergarten) in my calendar scheduled for this afternoon about that very topic. Luckily there's a traffic meeting this afternoon too, will add T271953 to the agenda [10:17:40] T271953: Add client TCP source port to webrequest - https://phabricator.wikimedia.org/T271953 [10:20:43] ema: ah ok I was not invited, good [14:23:38] * cdanis % google-chrome https://etherpad.wikimedia.org/p/Traffic-$(date -I -d 'Wednesday') [14:25:44] haha thanks [14:26:06] I see that the date command was updated :P [14:28:27] it updates itself ;) [14:28:45] although I also have a `-d 'last Wednesday'` in my history for when I need to peek back at history :) [16:05:27] 10Traffic, 10SRE, 10ops-eqiad: lvs1015 interface errors - https://phabricator.wikimedia.org/T272258 (10Cmjohnson) @BBlack Can you schedule this for this afternoon? [16:06:33] btw bblack I'm happy to push buttons re ^ if you're stuck in meetings, just would want to quickly discuss procedure with your first [16:06:36] 10Traffic, 10SRE, 10ops-eqiad: lvs1015 interface errors - https://phabricator.wikimedia.org/T272258 (10BBlack) @Cmjohnson Yes, just let me know a timeframe and we'll get it ready [16:09:50] 10Traffic, 10SRE, 10ops-eqiad: lvs1015 interface errors - https://phabricator.wikimedia.org/T272258 (10Cmjohnson) @BBlack Okay, 2 hours from now. 1300 EST [16:31:34] 10Traffic, 10SRE, 10ops-eqiad: lvs1015 interface errors - https://phabricator.wikimedia.org/T272258 (10BBlack) @Cmjohnson - we'll have it ready then. [18:14:10] 10Traffic, 10SRE, 10ops-eqiad: lvs1015 interface errors - https://phabricator.wikimedia.org/T272258 (10Cmjohnson) @BBlack I swapped both optics on lvs1015 and b2 xe-2/0/3 [18:27:38] 10Traffic, 10SRE, 10ops-eqiad: lvs1015 interface errors - https://phabricator.wikimedia.org/T272258 (10Cmjohnson) 05Open→03Resolved resolving this task, if the issue persists please re-open and ping me. Thanks! [18:49:20] 10netops: eqiad-esams link issue - https://phabricator.wikimedia.org/T272524 (10ayounsi) p:05Triage→03High [20:02:23] 10Traffic, 10SRE, 10ops-eqiad: lvs1015 interface errors - https://phabricator.wikimedia.org/T272258 (10BBlack) All appears healthy now and downtimes are removed, and librenms isn't showing those errors on the interface anymore, either. Thanks!