[14:02:13] bblack: I've built varnish 4.1.2-1wm1 and uploaded it to carbon together with all the vmods [14:02:51] and now having some fun with upgrades/downgrades on my test instance :) [14:02:58] nice! [15:18:57] o/ [15:19:49] After a while trying to figure out why vk needed the caching I decided to remove it, basically allocating only one logline and resetting it across log transactions [15:20:24] it is working fine at the moment, but I'd need to redo all the testing [15:20:39] to be super sure :) [15:21:56] yeah the caching seemed suspicious to me too, but I don't claim to understand vk very well [15:22:23] is there some operational reason it needs more than one logline at a time, e.g. to correlate frontend+backend halves of the transaction like varnishlogs -c and -b ? [15:22:33] (or maybe used to need that, but now doesn't with v4?) [15:23:24] so atm we only expand client transactions, discarding ESI and backend (more or less like ncsa) [15:23:48] we can probably safely ignore ESI, I don't expect us to ever really use it [15:24:02] but I thought some things we configure to pick up as VK fields, actually are backend? [15:24:51] basically if (t->type != VSL_t_req) gates backend transactions (in transactions scribe) [15:25:37] the grouping used is by request, so transaction_scribe is called with multiple transactions (like client, backend, etc..) [15:25:54] but all the data that we need is in client tags [15:26:43] and if we'll need in the future to allow also backends, we will be able with a little change in code [15:27:08] with the assumption that one logline will be emitted for each request [15:27:48] well the fields we query today for VK I think are the ones you see with: grep -w format modules/role/manifests/cache/kafka/* [15:27:55] having one log for client and one for backend could be possible too, but with a code change [15:28:18] oh yes I am using the same config that we have in prod [15:28:30] the new client tags are awesome [15:28:35] :D [15:29:20] since the old stuff was basically re-using varnishncsa's tag format stuff, and varnishncsa only did client-side, I guess that's what makes this all ok currently? [15:29:26] is that basically what you're saying above? [15:30:16] yep yep! [15:30:25] ok [15:30:33] sorry I might have dumped inconsistent things from my brain [15:30:41] probably a pretty nice reduction in code size/complexity to kill that logline cache anyways [15:30:44] anyhow, https://gist.github.com/elukey/c38c2220660cbb6d35ca is what I did today [15:30:56] that is basically the cache kill [15:31:42] ok, maybe do it as two separate patches, like it looks now [15:31:51] so we can mentally separate the existing work and then the cache kill [15:32:44] all right, do you want the bitmap code to be fixed in the code review out? [15:33:06] or just adding the new code review? [15:36:18] I think that only the new code review is less confusing, eventually we'll merge everything in one go probably [15:36:53] all right, I am going to work on it to target Tuesday/Wednesday as final dates for the code review [15:47:07] yeah just make it completely separate [15:47:29] the first big patch is "this all works, but the logline cache stuff is wrong and might leak loglines", and patch 2 "this kills the logline cache and cleans up related things" [15:55:19] got it :) [16:03:51] 10Traffic, 10MobileFrontend, 6Operations, 3Reading-Web-Sprint-68-"Java and JavaScript are basically the same", and 4 others: Incorrect TOC and section edit links rendering in Vector due to ParserCache corruption via ParserOutput::setText( ParserOutput::getT... - https://phabricator.wikimedia.org/T124356#2151236 [16:29:54] 10Traffic, 10MediaWiki-Interface, 6Operations: Purge pages cached with mobile editlinks - https://phabricator.wikimedia.org/T125841#2151367 (10BBlack) With the parent resolved, do we need to look at wiping out any lingering corner-cases that are still cached in varnish? [17:15:04] 10Traffic, 10Beta-Cluster-Infrastructure, 6Operations, 13Patch-For-Review, 7Puppet: Fix puppet on deployment-cache* hosts in beta cluster - https://phabricator.wikimedia.org/T129270#2151441 (10BBlack) @Krenair - I've modified the patch substantially, can you re-check on deployment-prep that it solves the... [18:33:27] 10Traffic, 10Beta-Cluster-Infrastructure, 6Operations, 13Patch-For-Review, 7Puppet: Fix puppet on deployment-cache* hosts in beta cluster - https://phabricator.wikimedia.org/T129270#2151780 (10Krenair) >>! In T129270#2151441, @BBlack wrote: > @Krenair - I've modified the patch substantially, can you re-c... [18:57:31] 10Traffic, 10Beta-Cluster-Infrastructure, 6Operations, 13Patch-For-Review, 7Puppet: Fix puppet on deployment-cache* hosts in beta cluster - https://phabricator.wikimedia.org/T129270#2151889 (10Krenair) 5Open>3Resolved