[01:59:11] 10Traffic, 10Varnish, 06Operations: Configure varnish to use "Unconfigured domain" page for 404 Not Served (instead of generic error) - https://phabricator.wikimedia.org/T112316#3139133 (10Krinkle) [06:15:26] 10Traffic, 06Operations, 10Pybal: pybal doesn't fully manage LVS table leaving stale services (on IP change) - https://phabricator.wikimedia.org/T114104#1684739 (10Joe) The real solution for this is to dedicate real developer time to pybal to move it to use a FSM and a netlink-based python ipvs client. All... [07:14:12] 10Traffic, 06Operations, 06Performance-Team: What happened 2017-03-09 04:00 - 06:00 UTC - https://phabricator.wikimedia.org/T160109#3139359 (10Peter) a:05Peter>03None [10:13:16] 10Traffic, 10DNS, 06Discovery, 06Labs, and 3 others: multi-component wmflabs.org subdomains doesn't work under simple wildcard TLS cert - https://phabricator.wikimedia.org/T161256#3139736 (10grin) >>! In T161256#3138330, @Peachey88 wrote: >>>! In T161256#3138272, @grin wrote: >> I would expect some backgro... [13:15:41] _joe_: hey :) What's your take on cherry-picking https://gerrit.wikimedia.org/r/#/c/267008/ into the 1.13 branch? That should fix T82747 which seems quite important [13:15:41] T82747: pybal health checks are ipv4 even for ipv6 vips - https://phabricator.wikimedia.org/T82747 [13:16:55] <_joe_> ema: uhm, i'd honestly cut another minor [13:18:15] oh, time for 1.14 then! [13:18:51] <_joe_> ema: this change is potentially a bit larger than the ones we did lately [13:18:54] ema: assert_ is a deprecated (and obscure IMHO) alias for assertTrue [13:19:26] _joe_: agreed [13:23:04] volans: oh thanks! I knew it, then I forgot it, let's see how long before I start using assert_ again [13:23:19] rotfl [14:00:51] _joe_: I've added a new 1.14 branch to gerrit based on 1.13, cherry-picked mark's patch and opened https://gerrit.wikimedia.org/r/#/c/345340/ [14:01:06] patch applied by hand on pybal-test2001, looks fine so far [14:01:19] <_joe_> ema: why just cherry-picked that patch? [14:01:28] <_joe_> I would have based 1.14 on master [14:01:53] <_joe_> but well, I might have misguided you, sorry :/ [14:03:09] _joe_: oh, because of all the changes in 1.13 which I imagine we want to bring onto 1.14 as well [14:03:32] <_joe_> ema: those should be merged back in master [14:04:00] <_joe_> ema: actually we should develop on master and cherry-pick on the version branches [14:04:07] <_joe_> sorry I never noticed that [14:04:43] _joe_: OK so I'll merge 1.13 into master and then base 1.14 on it [14:05:29] <_joe_> yeah, that would be the idea I guess [14:05:35] sounds reasonable :) [14:09:25] 10Wikimedia-Apache-configuration, 10Wikidata, 10ArchCom-RfC (ArchCom-Approved), 06Services (watching): Canonical data URIs and URLs for machine readable page content - https://phabricator.wikimedia.org/T161527#3140362 (10daniel) This RFC is scheduled for discussion on IRC tonight, at 21:00 UTC (2pm PDT, 23... [15:16:50] 10Traffic, 06Commons, 06Operations, 10Wikimedia-Site-requests, and 2 others: Allow anonymous users to change interface language on Commons with ULS - https://phabricator.wikimedia.org/T161517#3140566 (10BBlack) Adding Traffic and myself and @ema to this. I don't think we've been aware of the uselang hack... [15:20:28] ema: see above, I only happened to randomly spot this topic when I clicked through the gerrit link when I happen to see this scroll by in -ops: [15:20:34] 14:46 < wikibugs__> (CR) Jforrester: [C: -1] "This needs sign-off from Performance (and possible Ops) before merge. Will ping them." [mediawiki-config] - https://gerrit.wikimedia.org/r/345342 (https://phabricator.wikimedia.org/T161517) (owner: Steinsplitter) [15:21:51] bblack: ugh, nice catch [15:40:07] ema: so, hypothetically we can add to real cookie variance without really disturbing the login-session stuff on the text cluster [15:40:55] where we do "Token=1" now, we could also do ";ULS=x" [15:41:20] but that would also require that MW emit "Vary:Cookie" for all anon pages that can be varied by ULS [15:41:43] (which might already be the case, but it might also be the case for lots of pages that aren't varied by the ULS cookie the client would still be sending) [15:42:03] what we really want here is X-Vary-Options or whatever the more-standardsy replacement was for that [15:42:46] I don't see a great interim answer without going down that whole rabbithole [15:43:37] if we just added the uls cookie tag to the uncacheable set like Session|Token, I think that would uncache a bunch of cacheable content that doesn't actually change output on ULS anyways (e.g. RL JS) [15:43:42] (or images) [15:44:44] or another way to think of that problem: the old solution of ?uselang at least hopefully didn't apply that query-param to every request on the whole domain, which is how a cookie applies [15:45:25] (also, I really have no idea what this ULS cookie looks like, especially the domain part. hopefully it's not wildcard to boot) [16:03:05] 10Traffic, 06Commons, 06Operations, 10Wikimedia-Site-requests, and 2 others: Allow anonymous users to change interface language on Commons with ULS - https://phabricator.wikimedia.org/T161517#3133989 (10Krinkle) > Adding Traffic and myself and @ema to this. I don't think we've been aware of the uselang hac... [16:05:32] bblack: in an ideal world, making uselang cacheable and using xkey for purging would seem the best choice? [16:09:38] otherwise I imagine we could deal with ULS=$lang same way as we do Token=1 but in a vcl hacky way that only does that on requests that need to change output on ULS... [16:25:21] ema: I don't think purge pays attention to Vary (but I could be wrong!) [16:26:19] the uselang thing (which is how it operates today) sucks, but I mean apparently it doesn't melt our whole world or we'd already be in trouble [16:26:44] I'm more worried that any plan that switches over to ULS cookies might have a bigger impact than appservers returning no-cache headers for ?uselang URLs [16:33:26] ema: I'm just now really re-reading the pybal conversation above. doesn't the plan discussed mean 1.14's diff from 1.13 is going to be bigger than just the ipv6 fix (also all master changes since 1.13 diverged?) [16:34:11] bblack: correct, see https://gerrit.wikimedia.org/r/#/c/345370/ [16:34:35] we would need to test it with care [16:47:08] 17:44 < bblack> or another way to think of that problem: the old solution of ?uselang at least hopefully didn't apply that query-param to every request on the whole domain, which is how a cookie applies [16:47:37] the current approach actually appends ?uselang=$lang to all requests after you've chosen a language [16:48:47] oh, but I now see what you mean, it doesn't appply that to things like .js files and such [16:49:17] only to the actual links you click on [16:50:42] 10Traffic, 06Operations: Select location for Asia Cache DC - https://phabricator.wikimedia.org/T156029#3141009 (10Aklapper) Environmental discussion seems to be better at https://meta.wikimedia.org/wiki/Sustainability_Initiative (mentioned already in this task) and now https://wikimediafoundation.org/wiki/Reso... [16:54:15] ema: correct [16:54:51] ema: re: pybal - I think that's scarier than necessary. I mean whatever branching/merging/releasing plan we have, we should be able to move from $stable_deployed_code to $stable_deployed_code+1bugfix, without bringing in other untested changes... [17:01:28] bblack: true [17:02:17] so as input, how I've handled that with git branches in the past that I like (but there's a thousand ways), is like: [17:02:18] so far I've only merged 1.13 into master, we can discuss further how to best cut the 1.14 release [17:02:59] 1. master is ongoing development. maybe you don't merge features into there until they're complete and somewhat tested, but still it's going to diverge from previous releases and have new risks. [17:04:35] 2. When you get to a point where you want to cut a new feature-release, you cut a branch from e.g. master->1.14 At this point other new changes can pile into master that might be in 1.15 or 2.0, they don't affect the 1.14 branch. [17:05:16] 3. When you find a bug that's only in master, clearly that goes in master. If you find a bug that applies to master + 1.14, you'd probably commit the fix to master first and cherry-pick it to the 1.14 branch to use it in 1.14.1 release [17:05:31] (or if you find a 1.14-only bug, you'd just make the fix directly on the 1.14 branch) [17:05:48] but this all kind of assumes the 3-tier semver-type versioning, too [17:06:09] <_joe_> that's exactly what we have been doing, minus ema's 1.13 only patches :) [17:06:22] ok [17:06:35] <_joe_> and I'm sure that's my fault as I'm the one who told him what to do [17:06:38] so yeah the new patches that are in 1.13, assuming they're applicable to master (not 1.13-only bugfixes), need to merge back into master [17:07:09] <_joe_> yeah I think ema just did that [17:07:21] but if we've got 1.13 deployed today, and we need 1 new bugfix - you can commit that in master and pick to 1.13 or vice-versa, but it should still lead to a 1.13.1 we can deploy with only the fix [17:07:26] or however our versioning works [17:07:41] we shouldn't deploy new features just to get a bugfix out [17:08:01] but I don't think we even have semver, so I'm sure 1.13.1 is confusing in this too [17:08:13] I'm not really sure what pybal's version semantics actually are tbh [17:12:32] I guess it would be 1.13.6, seems changelog does use semver-like versioning [17:15:45] yeah the current situation is that master has all the 1.13 changes (none were 1.13-specific but rather new features / non-1.13-specific bugfixes) [17:18:33] and master has a list of changes that don't exist in the 1.13 branch (including the ipv6 fix, but also some other work) [17:18:40] correct [17:19:02] so, cherry-pick the ipv6 fix to 1.13 branch, cut 1.13.6 from there? [17:20:07] yeah, rinse and repeat for the other patches after appropriate testing [18:20:20] <_joe_> my idea to cut 1.14 was that that's not a trivial fix IIRC [18:20:43] <_joe_> and I'm not sure it's working as expected, tbh [18:23:25] ema: if they're true bugfixes, sure [18:23:35] I thought there was some feature-work in master, too, but I haven't looked hard in a while [19:39:15] 07HTTPS, 10Traffic, 06Operations, 15User-fgiunchedi: Enable HTTPS for swift clients - https://phabricator.wikimedia.org/T160616#3105285 (10aaron) SwiftFileBackend will need to force an https URL when it gets the storage_url back in the JSON auth response. [19:41:28] 10Wikimedia-Apache-configuration, 10Wikidata, 10ArchCom-RfC (ArchCom-Approved), 06Services (watching): Canonical data URIs and URLs for machine readable page content - https://phabricator.wikimedia.org/T161527#3141592 (10GWicke) >>! In T161527#3135095, @Smalyshev wrote: > I think we have several concepts t... [19:47:46] 10Wikimedia-Apache-configuration, 10Wikidata, 10ArchCom-RfC (ArchCom-Approved), 06Services (watching): Canonical data URIs and URLs for machine readable page content - https://phabricator.wikimedia.org/T161527#3141614 (10daniel) @GWicke yes, indeed. This ticket is not about concept URIs, but about URIs for... [19:49:43] 10Wikimedia-Apache-configuration, 10ArchCom-RfC, 10Wikidata, 06Services (watching): Canonical data URIs and URLs for machine readable page content - https://phabricator.wikimedia.org/T161527#3141618 (10daniel) [20:36:16] 10Wikimedia-Apache-configuration, 10ArchCom-RfC, 10Wikidata, 06Services (watching): Canonical data URIs and URLs for machine readable page content - https://phabricator.wikimedia.org/T161527#3141815 (10GWicke) I think the URL most users would consider canonical is /wiki/{title}. Wouldn't this already provi... [21:03:15] 10Wikimedia-Apache-configuration, 10ArchCom-RfC, 10Wikidata, 06Services (watching): Canonical data URIs and URLs for machine readable page content - https://phabricator.wikimedia.org/T161527#3142020 (10Smalyshev) `/wiki/{title}` assumes HTML representation. If we could make it content-negotiate to another... [21:08:34] 10Wikimedia-Apache-configuration, 10ArchCom-RfC, 10Wikidata, 06Services (watching): Canonical data URIs and URLs for machine readable page content - https://phabricator.wikimedia.org/T161527#3142032 (10matmarex) [22:15:43] 10Wikimedia-Apache-configuration, 10ArchCom-RfC, 10Wikidata, 06Services (watching): Canonical data URIs and URLs for machine readable page content - https://phabricator.wikimedia.org/T161527#3142369 (10daniel) /wiki/{title} is the user interface URL. I think it makes sense to have a separate URL for the da... [22:49:20] 10Traffic, 10Fundraising-Backlog, 10MediaWiki-extensions-CentralNotice, 06Operations, and 3 others: Purge Varnish cache when a banner is saved - https://phabricator.wikimedia.org/T154954#3142439 (10DStrine) [23:46:58] 10Wikimedia-Apache-configuration, 10ArchCom-RfC, 10Wikidata, 06Services (watching): Canonical data URIs and URLs for machine readable page content - https://phabricator.wikimedia.org/T161527#3134380 (10MZMcBride) From the current task description: ``` Problem: There is currently no canonical URI/URL for r...