[07:29:13] volans: whenever you have time (minus 8:30-9:00AM UTC), I'm ready to connect [07:31:11] * gehel status on data import [07:31:43] wdqs1009: chunk 863 / 982 [07:32:30] wdqs2008: chunk 908 / 982 [07:32:35] we're getting there... [07:45:09] now I only need a cookbook in time for that :/ [07:49:57] zpapierski: good morning, I'm around and available [07:53:51] great - join me here https://meet.google.com/xro-ivox-bkn [07:55:30] volans: ^^ [07:55:40] ack [09:02:10] Emmanuel: I'm in https://meet.google.com/fvg-axbh-tru if you are around [09:08:17] Emmanuel: if you have time to meet with dcausse today, that would be great! [09:11:44] break [09:12:38] Hi dcausse [09:12:45] Emmanuel: hey! [09:15:05] Emmanuel: I'll schedule some time with you today, please feel free to change the schedule to your convenience [09:15:36] Alright [09:15:43] dcausse: Emmanuel does not have his @wm.o email yet, but you can invite him on his private address [09:15:59] oh ok, doing so [09:56:19] lunch [10:22:55] volans: how does one release a spicerack patch? [10:23:07] zpapierski: +1ed the spicerack patch, as I guess you might not have +2 in that repo I'm happy to merge it too unless you'd like to get a final feedback from someone in search [10:23:32] I think I'm fine, already got a review from David [10:24:38] ack [10:48:00] lunch [12:00:17] Emmanuel: have you received the email from office IT with your credentials ? [12:16:59] Yes [12:17:21] It requires 2 Factor Auth [12:24:03] Emmanuel: let me check how to get that second factor... [12:24:41] Looks like your onboarding confirmation email should contain your 2-factor backup codes [12:25:03] if you don't find them, send an email to techsupport@wikimedia.org with me in cc [12:27:23] Already did [12:28:33] I haven't seen the email. Can you make sure you cc me on those kind of requests in the future? So I can also follow up? Thanks! [12:30:44] I responded to the email response that was sent to you from Techsupport [12:33:23] Emmanuel: please try to rejoin [12:33:33] Ok [12:34:31] strange, I see the reply from Josh, but not your email [12:35:49] volans: thanks for the merge! What are the next steps? or is it already available with cookbook? [12:35:56] (actually that I can check) [12:36:57] zpapierski: I've just released it (see SAL), was about to install and test on cumin2002 the new release (for things that changed) [12:37:08] it's available in pypi, so in cookbook's CI [12:37:48] what's pypi? [12:38:33] dependency repository, https://pypi.org/, the equivalent of npm for python in lame terms [12:38:54] ah, thx [12:39:09] so I can replace the version in cookbook? [12:39:13] that's from where the deps come from when you do pip install [12:39:29] no need to replace anything, if you just 'recheck' your patch on gerrit it will get the latest [12:39:37] spicerack is not pinned on purpose [12:39:50] locally you might have to rm -rf .tox [12:39:57] for the already mentioned pip issue ;) [12:40:15] I remember, thx [13:06:11] zpapierski: I've upgraded spicerack on the cumin hosts so it's available already also for the cookbooks [13:06:44] lmk if there is anything I should test for the kafka bits, the spicerack.Spicerack.kafka() accessor works fine [13:06:59] if there is some test command I could run I'd be happy to test them, both dry-run and not [13:07:47] thx! [13:08:41] Emmanuel: following up on IDEs - once you get access to office wiki, check this out - https://office.wikimedia.org/wiki/JetBrains [13:32:35] zpapierski: a small improvement that we could do to ConsumerDefinition is use @dataclass(kw_only=True, frozen=True), see https://docs.python.org/3/library/dataclasses.html for the details [14:01:33] "too many local variables", I'm not going to like you, prospector [14:03:20] zpapierski: it's totally ok to skip that in a cookbook [14:03:28] as in adding the ignore/disable comment [14:03:37] no worries, I can easily make it happy [14:05:00] in general in cookbooks we're less strict and it's normal to have a lot of self.* locals in the runner's __init_- [14:05:10] zpapierski: ok [14:12:04] and ofc ignore my prev note about kw_only, has been just recently added (3.10) [14:18:05] volans: looks nice, though [14:27:56] gehel: I have a green build on cookbook, but I see you're somewhat packed in the calendar, so we can pick the testing up tomorrow if you want [14:30:55] zpapierski: tomorrow morning is fairly packed, but let's try in the afternoon. I usually go out for lunch with France on Wednesday, but I should be back by 2pm [14:31:56] * gehel will run to the grocery store and be back in 20' [14:35:04] gehel: ok, I'll ping you then [14:53:36] Emmanuel: did you get your Google account sorted out ? [14:54:01] I am yet to get any reponse yet [14:55:34] Emmanuel: can you send me a copy of your last email on that thread ? [14:56:12] Josh Lam (WMF Internal) [14:56:12] Oct 12, 2021, 5:33 AM PDT [14:56:13] Thank you for letting us know. I will escalate this to one of our Workspace Admins so they can retrieve your backup codes. Will give you an update as soon as I hear back. [14:56:55] And I am yet to get any feedback since then [14:57:09] I'll ping Josh on slack [15:02:17] Ok Thanks [15:06:22] \o [15:23:08] \o/ Emmanuel should now have received his access to Google Apps! [15:23:20] Yes [15:23:29] I just logged in [15:23:35] Thanks a lot [15:23:39] Time to change your password! [15:23:50] On it [15:26:54] Emmanuel: can you also join Slack as soon as you can? https://wikimedia.slack.com/ [15:27:04] should be also your Google credentials [15:27:25] Yes it is [15:28:32] Emmanuel: do you also have access to Office Wiki (https://office.wikimedia.org/) ? [15:30:47] Emmanuel: also getting a real IRC client should probably be pretty close to the top of your priority list. IRCCloud works fine: https://office.wikimedia.org/wiki/ITS/IRCCloud [15:31:13] zpapierski: we have to come up with an answer for initial oauth state, since lvs can't do sticky sessions. Do we need to write a kask cache impl or use something else? [15:32:25] ebernhardson: I'm not a fan of that solution, but it seems we might not have a choice [15:32:38] I was thinking we could limit use of it only to initial authentication [15:32:46] and follow up with JWT authentication [15:33:06] this way we could limit the impact of external service [15:33:24] and each cache entry would be required for only short amount of time [15:33:26] wdyt? [15:33:41] yes we can still use a signed token that basically says 'user can issues queries for x hours` [15:33:49] yep [15:33:58] oh, other problem. you don't have any usernames here :P [15:34:11] but the whole point was to allow blocking users [15:35:06] I know, we discussed it at some point, can't remember why we didn't implement it [15:35:23] but I don't think it would be complicated [15:35:55] i can probably figure something out, it's looking tedious thogh [15:36:47] We need a signed request against Special:OAuth/identify, have to fit it into the existing oauth lib somewhere [15:37:06] don't we already do that? [15:37:18] you only call endpoints the oauth lib knows to clal [15:37:30] ah, right [15:37:34] the oauth lib doesn't seem to know anything about an identify endpoint (might be mw specific) [15:37:43] actually I think there's one more, but in general you're correct [15:38:10] my suggestion - let focus on making the distributed part work, and discuss user banning later [15:38:35] but then we did all the work and it doesn't actually do what we need it to :P but sure [15:38:50] I think the reason it wasn't implemented before is because the feature would be incomplete anyway without the mechanism to actually provide usernames for banning [15:39:35] hmm, oh this is embedded inside jetty inside blazegraph, we can't just restart it to reload? [15:39:49] do we also need some custom reload-config endpoint? [15:39:59] not having a username isn't the end of the world. We can always add that later when we actually need it. [15:40:27] We need to have authentication in place from the start, because it is going to be a lot more user impacting if we want to add it later. [15:40:35] gehel: i'm not sure we can, when we need this will be the middle of an incident. Not the best time to figure out how to OAuth sign custom requests :) [15:40:44] i guess [15:41:37] I agree with ebernhardson here, but I'd start with making this work the same way it works now (more or less), then figure out how to do username banning properly [15:41:57] I mean, I agree with you both, basically :) [15:42:31] ebernhardson: as for reload, after deployment you have to restart blazegraph [15:43:04] we should probably change the name of the service to jetty or something, but for now I think we can live with it [15:44:02] zpapierski: hmm, seems heavy handed to restart all of blazegraph to reload config in one place, but for a first run i guess we can live with it. Does blazegraph shutdown/startup quickly and cleanly? [15:44:47] I'm not sure, I never had any issue with it, but that proves nothing [15:45:01] :P [15:45:09] dcausse: can blazegraph be safely restarted? [15:45:15] in some cases (heavy load) it can take a minute to shut blazegraph down [15:45:18] zpapierski: what do you mean? [15:45:22] ah, ok [15:45:29] it starts up pretty fast [15:45:54] as in, is blazegraph shutting down gracefully, but from what gehel wrote I assume it does (or at least tries to) [15:46:05] we restart blazegraph during deploys so yes it's safe [15:46:12] i guess if we are banning a user we are already having some load incident, the service would already be spotty and a restart isn't much different [15:46:49] ok, sounds fine to not worry about how that config gets reloaded then. Just pull from the standard startup [15:46:50] huh, I actually didn't think about it and was thinking about adding some api to ban users [15:46:52] yeah, that's the least of our problem, we can improve with auto reload of configuration at some future point if it becomes an issue [15:47:16] but generally that's exactly what will happen - some user is killing the service and we need to ban [16:01:57] Emmanuel's welcome party is starting in https://meet.google.com/ryi-tyyv-wag [16:02:21] ryankemper: if you are around ^ [16:44:16] Status on wdqs data reload: [16:44:36] wdqs1009: chunk 893 / 982 [16:44:50] wdqs2008: chunk 932 / 982 [16:46:28] nice! [16:47:06] dcausse: assuming that cookbook will be ready tomorrow - do we have all to continue with migration? [16:48:08] zpapierski: yes but I fear that the data reload will take longer and requires couple more days so the data-transfer will have to start next week [16:48:59] as I think guillaume reports of the main dataset not including lexeme [17:07:30] Yep, only the main data [17:13:55] dcausse: I saw your note about streaming updater data transfer being delayed. What's the current status and expectation? [17:14:14] I know we thought a week might be more than enough time. is the data reload likely to eat up that buffer? [17:16:36] mpham: assuming we continue at the same pace (1B imported/24h) the reload might end in 24hours [17:17:50] + 24h - 48h to catchup the lag this means the data-tansfer starts thursday best case or friday which I think is too short to finish this week [17:19:51] What do you think a realistic ship date then is? Next Fri (22 Oct)? [17:20:34] mpham: yes, might be sooner if we're good at chaining the data-transfers [17:24:09] Ok, I won't update the mailing list yet, but i'll update in the #wdqs slack channel. Let's check back in after the data reload (and catchup) finishes and we have a better idea of the timeline to update the community [17:25:40] mpham: fine by me, thanks [17:56:34] dinner [18:27:50] ebernhardson: I think I accidentally claimed your user/color in the stand up etherpad, but I can't change it now. Change it to Erik (or "Not Trey" or whatever) if you want... [18:28:12] lol, it does say i'm trey somehow :P [18:28:34] I think it lets you name unnamed people, but not change them afterward. Kinda weird [18:28:59] ahh, that would do it [21:54:52] * ebernhardson always ends up puzzling on the questions that should be easy....how do we name the keys we write into session store :P