[07:21:55] addshore: since you linked https://github.com/wbstack/queryservice-updater during our meeting yesterday, I'm having a look. [07:22:22] I might have a few PR coming your way, just for fun. Let me know if they make sense at all. [07:23:07] Would you be interested in me trying to integrate this project with our usual parent pom? This would add a number of standard static analysis tools. [07:30:22] Sounds great IMO [07:30:41] If we need to touch it we might struggle potentially, as we have CI setup doing an integration test for this in github [07:31:58] I assume the Github builds are giving feedback on the PR? If so, I'll check they don't break. [07:34:45] yes! [07:48:34] something will have to change with the updater too (probaly its interation with the event api it uses) when we have 2 backends for the same graph namespacve too [07:48:50] but, thats for future us to worry about [07:49:36] The general idea being, any number of wikis can be split accross any number of backends, and also that we can load new backends on new wdqs code for wikis, while keeping the old ones and then transitioning traffic etc once loaded [08:20:36] addshore: I had some fun: https://github.com/wbstack/queryservice-updater/pull/50 [08:20:57] I should probably have made 2 PR, but I'm too much used to gerrit by now :/ [09:14:36] looks nice, i just enabled CI for you, lets see fi it is green :D [09:23:49] its green! [09:33:43] gehel: and deployed :) [09:33:58] addshore: thanks! [09:37:53] dcausse: re: your comment (https://gerrit.wikimedia.org/r/c/operations/software/spicerack/+/723214/comment/6a0cf5a3_2bb510db/) - I assume that this is only about timestamp, we will not need to manually note and set offsets here as well? I imagine if that ever will be the case, there's already enough tooling around it [09:41:08] zpapierski: yes only the timestamp can be provided by the operator when running the data-reload cookbook, dealing with offsets manually is very lowlevel imo and should never be needed (I hope) [09:41:55] agreed [09:47:50] another option I forgot to comment about but might be useful (perf wise) is max_poll_records=1 to avoid fetching too many messages [09:55:31] Lunch [10:00:24] lunch 2 [10:03:08] relocating and probably lunch as well [11:05:31] @gehel should I move scholarly article and labels tickets to needs reporting? maybe also commenting links to the wikitech pages? [11:11:47] tanny411: yes, please do ! [11:11:51] And thanks ! [11:11:59] great! [14:53:34] going offline, have a nice weekend! [15:02:40] \o [15:12:40] gehel: if you're around https://gerrit.wikimedia.org/r/c/operations/puppet/+/723314 should fix icinga complaining about something missing (maybe, i can't find the error message. But a few people mentioned it) [15:17:55] ebernhardson: Stuck with screaming kids for a few more hours [15:18:06] Maybe ryankemper can have a look [15:19:14] no worries :) [16:21:07] hmm, wcqs finished load but didn't become available: 2021-09-23T20:11:57+00:00 Data reload complete, switching active namespace [16:21:09] Namespace wcqs20210907 is in the alias file, but does not appear to be present in Blazegraph. [16:25:26] hmm, maybe doesn't matter. Deleted the data-reload flag and a few example queries appear to work [17:16:05] Deployed https://gerrit.wikimedia.org/r/c/operations/puppet/+/723314, it fixed the issue [17:16:16] ebernhardson: the problem was this alert (now resolved): https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=alert1001&service=Check+correctness+of+the+icinga+configuration [17:38:17] ryankemper: thanks! [18:21:33] ryankemper: if you have some time, https://gerrit.wikimedia.org/r/c/labs/private/+/723307 should be a noop and will allow pcc to work against wcqs-beta-01 [19:39:40] done [19:45:42] nice, it even works :) [19:45:56] now to see if putting the new nginx config there breaks everything :P [19:47:07] it shouldn't, diff is only whitespace changes.