[03:55:50] 10Wikimedia-Apache-configuration, 10Operations, 10Chinese-Sites, 10Patch-For-Review, 10User-Urbanecm: All "zh-my" variant page views get 404 Not Found on zh.wikipedia.org - https://phabricator.wikimedia.org/T198371 (10Shizhao) 05Open>03Resolved [07:17:15] 10Traffic, 10DBA, 10Operations, 10Patch-For-Review: Framework to transfer files over the LAN - https://phabricator.wikimedia.org/T156462 (10jcrespo) The original scope isn't met by far: * No throttling except it is easy to implement with pv * It is not intelligent * Compression is only on/off, not configur... [09:37:47] 10Traffic, 10Operations, 10Patch-For-Review: Upgrade cache servers to stretch - https://phabricator.wikimedia.org/T200445 (10ema) [10:35:23] 10Traffic, 10Operations, 10Performance-Team, 10Wikimedia-General-or-Unknown: Search engines continue to link to JS-redirect destination after Wikipedia copyright protest - https://phabricator.wikimedia.org/T199252 (10Deskana) @Imarlier I don't have access to Google Webmaster Tools any more, nor was I parti... [10:59:33] 10Traffic, 10DNS, 10Operations, 10Release-Engineering-Team, and 4 others: Move Foundation Wiki to new URL when new Wikimedia Foundation website launches - https://phabricator.wikimedia.org/T188776 (10JAllemandou) [12:11:32] ema: I am adding the debian-glue CI job to operations/vhtcpd :) [12:48:53] hashar: thanks! [12:51:47] rechecked, debian-glue green: https://gerrit.wikimedia.org/r/#/c/operations/software/varnish/vhtcpd/+/448424/ [12:59:08] :D [13:08:54] \o/ [13:27:16] 10Traffic, 10Operations, 10Patch-For-Review: Upgrade cache servers to stretch - https://phabricator.wikimedia.org/T200445 (10ema) [13:37:31] 10Traffic, 10Operations, 10Performance-Team, 10Wikimedia-General-or-Unknown: Search engines continue to link to JS-redirect destination after Wikipedia copyright protest - https://phabricator.wikimedia.org/T199252 (10Imarlier) >>! In T199252#4454769, @dr0ptp4kt wrote: > What's needed? @dr0ptp4kt within Se... [13:45:18] 10Traffic, 10Operations, 10Patch-For-Review: Upgrade cache servers to stretch - https://phabricator.wikimedia.org/T200445 (10ema) [13:52:15] so, varnish passes quite a few flags to cc_command by default: [13:52:21] -std=gnu99 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror -Wno-error=unused-result -pthread -fpic -shared -Wl,-x -o %o %s [13:53:02] we override that if geoiplookup is enabled (to pass -lmaxminddb basically) -> -fpic -shared -Wl,-x -L/usr/local/lib/ -o %%o %%s -lmaxminddb [13:53:53] (a) we do skip a few interesting flags if geoiplookup is enabled, we should probably add those back [13:54:32] (b) on stretch, inline C compilations fail because of -Wno-error=unused-result [13:55:11] https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/448525/ addresses (b) but perhaps we should take care of (a) in the same patch too? [13:59:38] 10Traffic, 10Operations, 10Patch-For-Review: Upgrade cache servers to stretch - https://phabricator.wikimedia.org/T200445 (10ema) [14:03:35] I'm not sure as to the origin of all those flags, but in general I'm philosophically opposed to Werror being automated anywhere [14:03:47] and if you kill Werror, you don't need Wno-error either [14:04:14] the warnings are kinda iffy anyways, as we're never going to see them in practice [14:04:30] which is I guess why whomever (might've been me for all I know) put in the Werror stuff [14:04:33] but still [14:04:36] warnings are warnings :P [14:04:51] :) [14:05:36] so should we set cc_command to varnish's default, but killing Werror and Wno-error? [14:06:05] oh those are from default, I see [14:07:15] I guess as a compromise, just remove the "-Werror -Wno-error=unused-result" substring, and align geoip with it [14:07:32] (but leave the other warn flag sand Werror=format-security) [14:07:38] k [14:09:51] my take on this issue in gdnsd is I have autoconf define a shitload of warnings (basically every reasonable warning, that doesn't spam on reasonable code), but the autoconf script also checks each one for compiler support and filters out the ones that don't work becaues they're compiler/version -specific. And then I don't use Werror, but I do in general demand that the code compiles warnings-cle [14:09:57] an for me, on the compilers I'm testing/developing with. But then it's impossible to ever gaurantee there won't be spurious warnings when other users compile with older or newer ones. [14:10:05] 10Traffic, 10Operations, 10Patch-For-Review: Upgrade cache servers to stretch - https://phabricator.wikimedia.org/T200445 (10ema) All dependencies are now in stretch-wikimedia. libvmod-netmapper and libvmod-re2 needed to be rebuilt because of updated dependencies. I've released a new debian version of vhtcpd... [14:11:05] the only exception there is I do define "-Werror=vla" if the compiler supports it. This is to enforce a coding standard that gdnsd doesn't use C99's VLA feature. [14:11:44] (VLA was required in the C99 standard, then later made into an optional extension for the C11 standard, and in either case it turns out to be one of those strcpy() sort of cases: any way you use it, even though it seems like a good idea, it's a bad code smell and a risk) [14:13:51] VLA allows defining stack arrays of lengths unknown at compile time, like: foo(int s) { int ary[foo]; for (i = 0; i < foo; i++) { ary[i] = ... } } [14:14:01] oops [14:14:09] VLA allows defining stack arrays of lengths unknown at compile time, like: foo(int s) { int ary[s]; for (i = 0; i < s; i++) { ary[i] = ... } } [14:15:07] without VLA, you'd either have to malloc() that array (which is a perf hit, malloc can take locks or cause other inter-thread contention, and is a library call), or you'd have to define "ary" with a static size like "int ary[1024]", which is larged than the maximum expected 's' parameter. [14:15:56] the problem is, at runtime "s" could be unreasonably huge and break your stack space (e.g. s = 2^31), causing a crash or worse [14:16:48] if as the author, your response to that problem is "Yeah, but I actually know s can never be bigger than 1024, which is a reasonable size on the stack"... well then you should assert that somewhere and simply define a static "int ary[1024]" :P [14:17:07] and if you know it can be huge in some cases and you want that to work, then I guess you should be using malloc rather than the stack :P [14:18:31] so basically, it's really a feature that never should've existed [14:18:58] (but it does making life simpler, if you ignore the problems. I got swept up in using it as a convenience crutch before I realized) [14:26:49] bblack: cache::text stretch VM up and running :) [14:26:56] woo [14:27:05] as in all the packages work? [14:27:08] basic varnish functionality works, varnishkafka doesn't crash, vhtcpd is alright too [14:27:25] https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/448525/ is needed for puppet runs to work though [14:28:29] ema: I don't know the derivation of those default flags, but can you check what they are on jessie too? they might differ [14:28:50] (hopefully not in ways that break linking up modules though!) [14:29:45] they're in varnishd's man page on pinkunicorn, but double-checking won't hurt [14:31:05] (testing on a jessie vm) [14:34:29] restarted both frontend and backend with those flags on stretch and jessie, thumbs up [14:36:03] (assuming "if it compiles it works") [14:36:12] :) [14:37:07] I forget, but does that mod to the systemd unit file force a restart of all the varnishes? [14:37:20] I'd think we set it up to not do that [14:38:59] it doesn't, it should trigger a systemctl daemon-reload though [14:40:06] mmh cc_command needs to be updated on vtc files too [14:53:08] well.. finally I'd be able to run integration tests with the ACMEv2 testing daemon from our CI environment <3 [14:53:31] :) [14:53:46] and it will work locally also, you only need to have pebble on your PATH [14:54:23] I avoided uploading X509 for pebble by simply generating them with our X509 library on test runtime [14:55:20] I'm puppet-compilering my cp1075-99 series, I think it's about done [14:56:13] nice! [14:56:15] (well, done enough to not break existing hosts. I'm sure there will be followup fixes after trying to puppet 1075, if nothing else dialing in the exact storage size) [15:01:04] * ema thanks the elders for sed [15:01:57] hahahah [15:10:12] hmmm aes128-sha usage on 0,05% and tls1.0 on 1.17%, lowest figures ever [15:10:22] vtc tests green on jessie/stretch cache_text VMs with updated cc_command(s) \o/ [15:10:46] cool [15:11:20] yeah the tls1.0 dropoff has been especially nice [15:11:32] I was getting worried it would never fall significantly and had already effectively floored out [15:14:22] hopefully by september we will be on <1% figures [15:15:39] do we have different puppet CI slaves running different puppet versions or something? [15:16:10] I have a very odd compiler failure for a fairly trivial amend to one that was working before. but I was running concurrently with another puppet compiler run, probably got myself pushed out to different nodes.... [15:17:16] re-running to see heh [15:18:18] hmmm wow.. globally we on the top 5 of alexa sites [15:20:55] i removed the import of the test package from the main module in pybal [15:21:10] i don't know why it was ever added, it seems to work fine without [15:21:45] mark: <3 [15:21:50] I mentioned that here a few months ago [15:22:00] yes, that's when I learned about it. thanks :) [15:22:58] and I made Travis CI now run tox, same as our CI infra [15:23:24] yup.. I see those changes passing by [15:23:25] a difference was twisted trial vs... whatever the default unittest runner is called [15:24:12] it's too hot to do serious coding today, so i just investigated the CI situation instead ;) [15:24:43] yey.. here it's crazy as well [15:24:51] 35ÂșC 70% humidity... a nightmare [15:24:57] even hotter here [15:25:22] somehow I managed to understand docker-pkg and figure out the integration tests for certcentral [15:25:46] :) [15:26:18] so on monday I should be in position to merge the ACMEv2 stuff [15:27:44] and give some love regarding testing to the http API of certcentral [15:27:52] and of course get rid of acme_tiny and use our own library [15:34:42] ema: those patches are merged for the cp1075-99 hw stuff. compiler says no-op everywhere else except a minor thing on cp1008 (already done) [15:35:08] bblack: awesome! [15:35:10] I've gotta take off for the day shortly though, so I'm not gonna test puppetization on the new hw until monday [15:35:34] (or maybe earlier if I get particularly unbusy and bored or it's too hot outside heh) [15:36:16] bblack: ok, we can merge the cc_command patch on Monday and play with our first stretch cache nodes in prod then :) [15:57:04] 10Traffic, 10Operations, 10Patch-For-Review: Pick up a suitable ACME library for certcentral - https://phabricator.wikimedia.org/T199717 (10Vgutierrez) [15:57:08] 10Traffic, 10Operations, 10Continuous-Integration-Config: Provide a CI container with pebble - https://phabricator.wikimedia.org/T200405 (10Vgutierrez) 05Open>03Resolved [18:53:25] 10Traffic, 10Operations, 10Phabricator, 10Zero: Missing IP addresses for Maroc Telecom - https://phabricator.wikimedia.org/T174342 (10Aklapper) [20:58:59] 10HTTPS, 10Traffic, 10Discovery, 10Operations, and 2 others: Consider switching to HTTPS for Wikidata query service links - https://phabricator.wikimedia.org/T153563 (10Smalyshev) [20:59:03] 10HTTPS, 10Discovery, 10Operations, 10WMDE-Tech-Communication, and 2 others: announce breaking change: http > https for entities in rdf - https://phabricator.wikimedia.org/T154015 (10Smalyshev) 05stalled>03declined Since parent is declined, declining this too. [20:59:26] 10HTTPS, 10Traffic, 10Discovery, 10Operations, and 2 others: compile number of http uses for http://www.wikidata.org/entity - https://phabricator.wikimedia.org/T154017 (10Smalyshev) 05stalled>03declined [20:59:30] 10HTTPS, 10Traffic, 10Discovery, 10Operations, and 2 others: Consider switching to HTTPS for Wikidata query service links - https://phabricator.wikimedia.org/T153563 (10Smalyshev) [20:59:57] 10Traffic, 10Operations, 10Performance-Team, 10Wikimedia-General-or-Unknown: Search engines continue to link to JS-redirect destination after Wikipedia copyright protest - https://phabricator.wikimedia.org/T199252 (10Imarlier) a:03Imarlier [21:09:10] 10Traffic, 10Operations, 10Performance-Team, 10Wikimedia-General-or-Unknown: Search engines continue to link to JS-redirect destination after Wikipedia copyright protest - https://phabricator.wikimedia.org/T199252 (10Imarlier) Here's what I know at this point: 1. Google did, in fact, last index it.m.wik... [21:10:35] 10Traffic, 10Operations, 10Performance-Team, 10Wikimedia-General-or-Unknown: Search engines continue to link to JS-redirect destination after Wikipedia copyright protest - https://phabricator.wikimedia.org/T199252 (10Imarlier) @dr0ptp4kt @Dzahn or others: Any chance of also giving me access to it.wikipedia... [21:18:42] 10Traffic, 10Operations, 10Performance-Team, 10Wikimedia-General-or-Unknown: Search engines continue to link to JS-redirect destination after Wikipedia copyright protest - https://phabricator.wikimedia.org/T199252 (10dr0ptp4kt) Update to the ticket: webmaster console access has been provided to Ian for htt...