[09:54:04] 10Wikimedia-Apache-configuration, 06Operations: catch-all apache vhost on the cluster should return 404 for non-existing sites - https://phabricator.wikimedia.org/T137176#2452012 (10fgiunchedi) p:05Triage>03Low triaging as low as I'm not sure of the actual impact (?) the things to do IMO would be: [] audi... [10:22:59] varnishtest tries to resolve phk.freebsd.dk every time you call it [10:23:04] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830843 [10:24:13] https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishtest/vtc_main.c#L616 [10:27:03] lol [10:28:26] This is because of varnishtest trying to resolve phk.freebsd.dk every time it is invoked to check if DNS works [10:28:31] ah nice [10:29:36] 10Traffic, 10Varnish, 06Operations: Install XKey vmod - https://phabricator.wikimedia.org/T122881#2452066 (10ema) varnish-module is now available for testing on apt.wikimedia.org (jessie-wikimedia/backports). [11:53:03] bblack: I know that you are super busy catching up with emails and tasks, but if you have time during the next days: https://gerrit.wikimedia.org/r/#/c/295652/ [12:50:05] 10Traffic, 06Operations, 13Patch-For-Review: Switch port 80 to nginx on primary clusters - https://phabricator.wikimedia.org/T107236#2452441 (10faidon) Perhaps we should wait until Varnish 5.0, supposedly out in a couple of months and with HTTP/2.0 support, before we proceed with this change? [12:51:41] 10Traffic, 06Operations, 13Patch-For-Review: Investigate TCP Fast Open for tlsproxy - https://phabricator.wikimedia.org/T108827#2452455 (10faidon) I don't particularly object into either moving port 80 to `sh` or to nginx, but I don't think that TFO on port 80 will make any kind of performance impact — at le... [12:53:20] 07HTTPS, 10Traffic, 06Operations, 10Wikimedia-Blog: Switch blog to HTTPS-only - https://phabricator.wikimedia.org/T105905#2452456 (10faidon) We (@Tbayer mostly) have asked for this repeatedly, to no avail. There was a thread with comms that hasn't seen any activity lately, I'll ping again… [12:56:48] 10Traffic, 06Operations, 13Patch-For-Review: Investigate TCP Fast Open for tlsproxy - https://phabricator.wikimedia.org/T108827#2452463 (10BBlack) @faidon - so far we've seen TFO stats showing more TFO failures than successes, so we're looking for reasons why TFO so commonly fails when attempted. That port... [13:05:31] bblack: thanks for the review! I think that the else branch (with the continue) is fine, but probably it is better to wrap it with braces to keep consistency with the other ones? [13:07:30] 10Traffic, 06Operations, 13Patch-For-Review: Switch port 80 to nginx on primary clusters - https://phabricator.wikimedia.org/T107236#2452527 (10BBlack) It will be another 6 months before we're even settled into a full Varnish 4 world. We have several major followup projects pending on that (e.g. xkey, and f... [13:07:49] elukey: I think it's actually-wrong, as in the wrong number of total braces [13:11:00] bblack: I checked the wrapping else if condition, the upper if one but I don't see it :( [13:12:38] elukey: ok I looked again, and you're right, it's actually functionally fine as it is. It's just confusing style-wise, which is why it confused me into thinking there's a missing brace [13:12:46] elukey: put opening and closing braces around the continue [13:12:59] sure I was about to do it [13:13:15] (basically if an if/else chain ever uses braces, it should use braces for all clauses. you only get to use the single-line mode if all clauses are single-line) [14:07:27] 10Traffic, 06Operations, 10Continuous-Integration-Infrastructure (phase-out-gallium): Move gallium to an internal host? - https://phabricator.wikimedia.org/T133150#2452957 (10hashar) doc.wikimedia.org home is tracked via T137890 [14:11:43] 10netops, 06Operations, 10Continuous-Integration-Infrastructure (phase-out-gallium): Relocate CI generated docs and coverage reports - https://phabricator.wikimedia.org/T137890#2452985 (10hashar) I have updated the task with a basic overview. The doc is generated on labs instances and rsync ed to the labs... [14:14:48] <_joe_> so, bblack, ema do you have 10 minutes for me? [14:16:05] _joe_: yep [14:16:09] _joe_: yes [14:16:17] wikidata-something? [14:16:48] <_joe_> yeah just a sec [14:18:25] <_joe_> I was just caught with a stupid typo [14:22:10] oh nice, this one fails on 32-bit architectures: https://github.com/varnish/varnish-modules/blob/master/src/tests/cookie/08-overflow.vtc#L33 [14:23:34] from reading up and playing with newer gcc/clang releases, it seems like more and more 32-bit bugs are going to pop up in various software... [14:24:36] basically the trend of exploiting undefined behaviors for optimization is increasing. code that doesn't strictly obey the nitty rules about signedness, promotions, overflows, etc... is gonna be hosed, and 32-bit will be affected worse in practice. [14:24:56] (because it's more likely to run into real issues with existing in-use bitfield flags or actual real-world byte lengths, etc) [14:25:05] happy times for debian porters :) [14:25:24] yeah heh [14:25:29] <_joe_> so [14:26:09] <_joe_> wikidata: wikidata folks have created a tool that "autogenerates" wiki pages from wikidata items [14:26:18] on other wikis, I assume [14:26:30] <_joe_> yes, on smaller wikis in particular [14:26:39] why smaller in particular? [14:26:40] <_joe_> to give a stub article editors can use as a start [14:26:49] <_joe_> because smaller wikis might need it [14:26:56] heh ok [14:26:57] <_joe_> smaller as in with less info [14:27:38] not really my area, but did they talk to the rest of the broader community about this? I could imagine some admins being annoyed at the idea of auto-generation of massive amounts of stubs that may never see updates [14:27:52] it's just article inflation with no real value [14:28:00] <_joe_> of course they did [14:28:05] <_joe_> it's the WMDE, not the WMF [14:28:07] <_joe_> ;) [14:28:12] :P [14:28:16] <_joe_> so the point where we come into play is [14:28:33] <_joe_> pages are currently uncached, and some are very fast to be generated [14:28:36] <_joe_> see https://nn.wikipedia.org/wiki/Spesial:AboutTopic/Q52179 [14:28:48] that's what the stub looks like? [14:28:52] <_joe_> yes [14:28:57] <_joe_> don't argue :P [14:29:08] <_joe_> so, other pages are very expensive to generate [14:29:11] <_joe_> see https://nn.wikipedia.org/wiki/Spesial:AboutTopic/Q2150573 [14:29:13] well, I clearly fail to understand the basic explanation [14:29:48] I thought the idea was, for example, if wikidata knows about a city named Ftyaz and the wiki doesn't have an article yet, it would create /wiki/Ftyaz as a populated stub article [14:29:51] <_joe_> these autogenerated pages can be easily templated by the community, too, IIRC. [14:30:09] <_joe_> no, it's not at the usual address [14:30:19] <_joe_> and it's generated on the fly with each request [14:30:31] <_joe_> if this kind of pages get indexed by google [14:30:34] so far this seems like a bad idea all around, but go on.... [14:30:44] <_joe_> it might become some non-negligible traffic [14:30:54] <_joe_> esp if it's activated on say ruwiki [14:31:02] <_joe_> ruwiki is interested in it [14:31:50] what's the purpose of these URLs in Special:AboutTopic/QNNNNN ? are they intended to be publicly indexed and consumed, or it is intended to be a tool that the wiki editing community knows about to go find and copy this stuff into a real article? [14:31:55] <_joe_> so the problem arises of: can we manage to not cache these pages? and if we can't afford it, what's more advisable to do, given purges of such generated pages would probably be a disaster? [14:32:07] <_joe_> both [14:32:18] <_joe_> so yeah they want those pages indexed [14:32:32] purges are already a disaster, and this seems like a horrible plan with little real benefit to users. how is this any better than just looking at QNNNNN on wikidata itself? [14:32:33] <_joe_> btw, if a page exists on the wiki the special page redirects to it [14:32:58] <_joe_> so for example https://nn.wikipedia.org/wiki/Spesial:AboutTopic/Q2 redirects [14:33:04] <_joe_> bblack: yeah I said no purges [14:33:16] purges are still better than uncacheable content [14:33:16] <_joe_> but OTOH we cannot afford not to cache such pages [14:33:35] <_joe_> they're extremely heavy computationally when they're of some complexity [14:33:48] IMHO, when viewed in the net of what we're doing on our end and how this impacts real human readers, this is a giant mess of complexity for virtually no gain AFAICS [14:34:17] <_joe_> so I was /thinking/ of suggesting them to send out cache headers to cache such generated pages for 1 day [14:34:26] why are we churning up all of this and exposing all of this data redundantly through new uncacheable URLs, and to what end for real humans? I can easily imagine the rate of these pages purging or regenerating being higher than the rate at which humans actually read unique articles [14:35:05] <_joe_> yeah that's why I said I don't think it's ok to cache for 1 day with no eviction [14:35:06] what's the justification, what's the expected traffic and impact on our end? [14:35:26] <_joe_> expected traffic, not big for now [14:35:51] <_joe_> but marius (hoo) wanted to tackle the issues with us before it was a production problem [14:36:02] <_joe_> as for the product rationale, I have no idea of course [14:36:13] <_joe_> let's set up a meeting with the wikidata people? [14:36:26] <_joe_> well for now let's see when they'll open a phab ticket on this [14:36:30] <_joe_> I asked them to [14:37:48] I just... don't see the benefit at all. Lots of churn and dynamicism, not driven by actual readers' pageviews but by internal "spread everything everywhere", carries redundant information easily findable at the real wikidata URL, etc... [14:38:03] and the downsides look big [14:39:29] maybe if we had a better idea what their actual aims are (as in, how this is improving things for what real users), we could talk about designing the mechanism to work in an efficient way and still meet those goals [14:40:01] so yeah, a meeting would be good, preferably back when they were designing this, but better late than never. [14:41:01] <_joe_> ok [14:41:10] <_joe_> let's see how they respond to my email [14:42:02] <_joe_> bblack: also, welcome back! [14:42:06] <_joe_> :D [14:42:31] :) [16:48:18] 10Traffic, 06Operations, 06Performance-Team, 10Wikimedia-Stream: HTTPS-only for stream.wikimedia.org - https://phabricator.wikimedia.org/T140128#2454047 (10BBlack) [16:49:11] 07HTTPS, 10Traffic, 06Operations, 10Wikimedia-Stream: stream.wikimedia.org doesn't redirect to HTTPS - https://phabricator.wikimedia.org/T137915#2454062 (10BBlack) [16:49:13] 10Traffic, 06Operations, 06Performance-Team, 10Wikimedia-Stream: HTTPS-only for stream.wikimedia.org - https://phabricator.wikimedia.org/T140128#2454063 (10BBlack) [16:49:49] 10Traffic, 06Operations, 13Patch-For-Review: Switch port 80 to nginx on primary clusters - https://phabricator.wikimedia.org/T107236#2454068 (10BBlack) [16:49:51] 10Traffic, 06Operations, 06Performance-Team, 10Wikimedia-Stream: HTTPS-only for stream.wikimedia.org - https://phabricator.wikimedia.org/T140128#2454047 (10BBlack) [16:50:08] 10Traffic, 06Operations, 06Performance-Team, 10Wikimedia-Stream: HTTPS-only for stream.wikimedia.org - https://phabricator.wikimedia.org/T140128#2454047 (10BBlack) [16:50:11] 07HTTPS, 10Traffic, 06Operations, 13Patch-For-Review: Enforce HTTPS+HSTS on remaining one-off sites in wikimedia.org that don't use standard cache cluster termination - https://phabricator.wikimedia.org/T132521#2454071 (10BBlack) [18:00:34] 07HTTPS, 10Traffic, 06Operations, 13Patch-For-Review: Enforce HTTPS+HSTS on remaining one-off sites in wikimedia.org that don't use standard cache cluster termination - https://phabricator.wikimedia.org/T132521#2201391 (10Boshomi) When this work is done, protocol-relative URLs should be declared as depreca... [18:24:13] 07HTTPS, 10Traffic, 06Operations, 13Patch-For-Review: Enforce HTTPS+HSTS on remaining one-off sites in wikimedia.org that don't use standard cache cluster termination - https://phabricator.wikimedia.org/T132521#2201391 (10demon) >>! In T132521#2454408, @Boshomi wrote: > When this work is done, protocol-rel... [21:56:25] 07HTTPS, 10Traffic, 06Operations, 10RESTBase, 05Security: Enforce HTTPS for authenticated public connections - https://phabricator.wikimedia.org/T88862#2455579 (10BBlack) This can probably be closed now, as all public RB access is via the standard cache clusters which are enforcing HTTPS, but defer to gw... [22:15:13] 07HTTPS, 10Traffic, 06Operations, 06Performance-Team, 10Wikimedia-Stream: HTTPS-only for stream.wikimedia.org - https://phabricator.wikimedia.org/T140128#2455672 (10Danny_B) [22:19:56] 07HTTPS, 10Traffic, 06Operations, 10RESTBase, 05Security: Enforce HTTPS for authenticated public connections - https://phabricator.wikimedia.org/T88862#2455697 (10GWicke) 05Open>03Resolved a:03GWicke @bblack, you did indeed resolve this without us doing anything. Many thanks, sir!