[13:16:29] <ema>	 bblack: or perhaps ensure => 'removed' on libvmod-header right before installing varnish-modules?
[13:17:39] <bblack>	 except that might leave varnishd broken in-between if it takes a while to run puppet on all
[13:18:03] <bblack>	 I guess in theory it should be ok as long as varnishd doesn't crash/restart? but I donno if it's an issue on spawning new threads for some obscure reason (probably not).
[13:18:30] <bblack>	 or loading new VCLs
[13:18:53] <bblack>	 almost definitely, an issue for running varnishtest with VCLs referencing vmod_header
[13:22:01] <ema>	 bblack: I wasn't thinking of two separate changes but rather something like:
[13:22:04] <ema>	         package { "libvmod-header":
[13:22:07] <ema>	             ensure => "removed"
[13:22:09] <ema>	         }
[13:22:12] <ema>	         package { [
[13:22:14] <ema>	             'varnish-modules',
[13:22:17] <ema>	             'libvmod-netmapper',
[13:22:19] <ema>	             'libvmod-tbf',
[13:22:22] <ema>	             'libvmod-vslp',
[13:22:24] <ema>	             ]:
[13:22:27] <ema>	             ensure  => 'installed',
[13:22:56] <bblack>	 require => Package['libvmod-header'] ?
[13:23:01] <bblack>	 could work! :)
[13:23:28] <ema>	 oh right, require is also needed
[13:24:13] <bblack>	 I think, confusingly, that will require its un-installation
[13:24:49] <ema>	 to guarantee the removal of vmod-header happens before -modules installation right?
[13:25:22] <bblack>	 right
[13:31:23] <ema>	 E: Version 'removed' for 'libvmod-header' was not found
[13:31:25] <ema>	 heh
[13:31:40] <ema>	 absent?
[13:31:45] <bblack>	 probably
[13:32:45] <bblack>	 yeah
[13:32:49] <ema>	 worked \o/
[13:52:44] <_joe_>	 oh btw, I wanted to share my experience during my time off, with a slow (640kb DSL) and high-latency network
[13:53:02] <_joe_>	 wikipedia seemed relatively much faster than most websites
[13:53:20] <_joe_>	 esp most things on TLS were dogslow
[13:53:38] <_joe_>	 not the wikis
[13:53:43] <_joe_>	 so, good job :)
[13:54:04] <ema>	 _joe_: perhaps enabling TFO in your browser could have helped a little
[13:54:10] <_joe_>	 when I say "high-latency" I mean I got 2-3 s ping RTT from 8.8.8.8
[13:54:30] <_joe_>	 ema: it is enabled since we tested it IIRC
[13:54:30] <ema>	 oh, that's high latency indeed :)
[14:00:55] <mark>	 i'm very often on a 500 kB DSL line
[14:01:05] <mark>	 though, fortunately it doesn't often have 1s+ latency :P
[14:01:24] <mark>	 in the past i've setup a linux box which delays packets by arbitrary amount of time to test that
[14:02:04] <mark>	 would be fun to route the entire office's traffic through that (we can do that >;-)
[14:03:48] <ema>	 mark: only once every two days though to sprinkle some additional madness
[14:04:09] <mark>	 well I wanted to do it when budgeting our asia caching data center
[14:04:14] <mark>	 >;-)
[14:04:16] <mark>	 but was a bit busy :(
[14:10:20] <wikibugs>	 10Traffic, 10Varnish, 10Analytics-Cluster, 10Graphoid, and 3 others: Graphoid access logs are missing from Hadoop - https://phabricator.wikimedia.org/T99372#2544017 (10akosiaris) parsoidcache has been deprecated and graphoid is now exposed via the text cluster. That solves the problem and graphoid logs sho...
[14:10:42] <wikibugs>	 10Traffic, 10Varnish, 10Analytics-Cluster, 10Graphoid, and 3 others: Graphoid access logs are missing from Hadoop - https://phabricator.wikimedia.org/T99372#2544018 (10akosiaris) 05Open>03Resolved a:03akosiaris
[14:11:45] <wikibugs>	 10Traffic, 10Varnish, 06Operations, 06Performance-Team, and 2 others: Vary mobile HTML by connection speed - https://phabricator.wikimedia.org/T119798#2544023 (10akosiaris)
[14:13:05] <wikibugs>	 10Varnish, 06Performance-Team, 06Reading-Web-Backlog, 13Patch-For-Review: Vary mobile HTML by connection speed - https://phabricator.wikimedia.org/T119798#2544027 (10akosiaris)
[14:16:04] <wikibugs>	 10Traffic, 10Analytics, 06Operations: Correct cache_status field on webrequest  dataset - https://phabricator.wikimedia.org/T142410#2544038 (10akosiaris) p:05Triage>03Normal
[14:16:44] <wikibugs>	 10Traffic, 10Analytics, 06Operations: Correct cache_status field on webrequest  dataset - https://phabricator.wikimedia.org/T142410#2544040 (10BBlack) 05Open>03Resolved a:03BBlack I think we're done here, assuming the data looks sane on the analytics end.
[14:45:31] <wikibugs>	 10Traffic, 10Varnish, 10MediaWiki-API, 06Operations: Evaluate the feasibility of cache invalidation for the action API - https://phabricator.wikimedia.org/T122867#2544097 (10ema)
[14:45:34] <wikibugs>	 10Traffic, 10Varnish, 06Operations, 13Patch-For-Review: Install XKey vmod - https://phabricator.wikimedia.org/T122881#2544095 (10ema) 05Open>03Resolved
[14:45:37] <wikibugs>	 10Traffic, 06Operations: Content purges are unreliable - https://phabricator.wikimedia.org/T133821#2544096 (10ema)
[15:14:13] <wikibugs>	 10netops, 06Operations, 10ops-eqiad: cr2-eqiad temperature alerts ("system warm") - https://phabricator.wikimedia.org/T141898#2544208 (10Cmjohnson) 05Open>03Resolved I adjusted the blanking panels and the fan speed as lowered   Fans  Top Rear Fan                   OK         Spinning at intermediate-spee...
[15:16:16] <wikibugs>	 10Traffic, 06Operations: Support TLS chacha20-poly1305 AEAD ciphers - https://phabricator.wikimedia.org/T131908#2544211 (10BBlack) Recording some related thoughts on performance and security:  = Server Perf:  This is openssl benchmarks, using our 1.0.2+cloudflare package, on our latest-gen cp hardware (this is...
[16:05:01] <wikibugs>	 10Traffic, 06Operations: Support TLS chacha20-poly1305 AEAD ciphers - https://phabricator.wikimedia.org/T131908#2544363 (10faidon) >>! In T131908#2544211, @BBlack wrote: > So for now, I recommend that we keep letting client preference make the call on this and see how things play out over the long run.  Yeah,...
[19:12:53] <wikibugs>	 10Traffic, 10MediaWiki-Cache, 06Operations, 06Performance-Team, and 2 others: Cached outdated revisions served to logged-out users - https://phabricator.wikimedia.org/T141687#2545091 (10Krinkle)
[19:33:32] <wikibugs>	 10Traffic, 06Operations: Support TLS chacha20-poly1305 AEAD ciphers - https://phabricator.wikimedia.org/T131908#2545144 (10BBlack)  > It's also interesting to make some observations about the AES 128-vs-256 debate while we're here...  The above was mostly a side-note, and was drawn from memory of reading over...
[20:46:56] <wikibugs>	 10Traffic, 06Operations: Support TLS chacha20-poly1305 AEAD ciphers - https://phabricator.wikimedia.org/T131908#2182588 (10Platonides) Don't forget about that timing-resistant AES implementation by djb. I thought people had been using timing-resistant AES implementations for years (assuming they used a modern...
[20:49:46] <wikibugs>	 10Traffic, 06Operations: Support TLS chacha20-poly1305 AEAD ciphers - https://phabricator.wikimedia.org/T131908#2545401 (10BBlack) >>! In T131908#2545388, @Platonides wrote: > Don't forget about that timing-resistant AES implementation by djb. > I thought people had been using timing-resistant AES implementati...