13:02:21 #startmeeting network-health 2025-07-14 13:02:21 Meeting started Mon Jul 14 13:02:21 2025 UTC. The chair is hiro. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:02:21 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:03:12 o/ 13:05:17 oook so we have a p183 meeting in about 1 hour and I have started filling over the pad: https://pad.riseup.net/p/project183-meeting-pad 13:05:29 GeKo (IRC): I think I am missing some bits about O1.2 13:05:55 i'll put stuff in after this sync 13:06:09 thanks 13:06:42 juga: do you want to do anything more for https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40228 ? 13:06:57 imo we might be done here, at least as far as relaybw is concerned 13:07:16 and which method have we decided to use for sbws? 13:07:29 or we do that at analysis#80? 13:07:29 Uhm, which one of [tpo/network-health/analysis, tpo/network-health/metrics/analysis] did you mean? 13:07:52 GeKo: ^ 13:08:33 we can do that there 13:09:09 once we have that properly analyzed. it's still missing a bit from my side 13:09:16 ok 13:09:22 which likely needs to wait until i am back 13:09:32 sounds reasonable 13:10:17 juga: then i'll add a small summary fo that sbws ticket and close it later today? 13:10:21 *to 13:10:28 GeKo: ok, thanks 13:10:39 k 13:12:13 kk, from my side for this week I plan to finish hopefully the bit about extracting onion services stats in rust with tor_fusion if there is time. My focus will be on making sure we have metricsdb-01 stabilized from what the system is concerned hopefully solving the I/O issues 13:12:41 Also GeKo (IRC) I plan to prepare all the dumps from you from the db 13:12:55 have you had a look at the files with consensuses? 13:13:11 i was just looking at the ones with the statuses 13:13:34 which seemed reasonable. and a per month thing is easier to digest 13:13:51 ok would you still need 6 months or more/ 13:13:52 ? 13:13:58 i need to ping ahf though figuring out whether we can put them easily in a local net at bornhack 13:14:08 let me get back to you after that 13:14:15 ok! 13:14:43 and finally it is also GSOC eval week, please 4xy0m send me and sarthikg all the code you have up to now, it doesn't have to be the best code but will give us an idea of where we are with things 13:14:53 you can tag the both of us as reviewer 13:14:59 *reviewers.. 13:15:15 also happy Bastille day if you celebrate 13:16:00 hiro: I'll do it right now 13:16:06 hiro: Haha thank you :') 13:17:02 my update: aggregator is taking its final shape. for the server_status table, it is all ready already, but for the new tables, I think i might need a bit more time. The MR should be coming sometime today or tmrw. apart from this, working on a datamodel repo which would include sea-orm entities & migrations which can be used as a crate across other rust projects 13:17:28 juga: we should do a sync with sarthikg about this 13:17:48 sarthikg[mds]: nice, entities and migrations :) 13:17:58 hiro: ok, when do you prefer? 13:18:02 this is something I think you had proposed too and you might have ideas about how to manage these tables 13:18:14 let me prepare a whentomeet 13:18:22 perfect 13:19:03 GeKo, hiro: should i focus on the issues to improve the DB views (line #73 in the pad) or focus on collector this week? 13:19:21 collector I think so we can move it forward 13:19:39 hiro: ok 13:20:05 let me stabilize the db, I was reading it could be the WAL files the db writes and since we have a lot of records it might mean a lot of wal files to write] 13:20:16 sgtm 13:20:23 which causes the I/O issues 13:20:24 i can then mark as backlog some of those issues and go back to them later 13:20:32 cool thanks 13:20:53 hiro: ah, i was experimenting with pg_partman an pg_cron locally last week, we probably would like to enable that in metricsdb.tpo too 13:21:14 ok, let's make an issue? 13:21:26 sure, i'll create one in a bit 13:21:35 at metrics-sql-tables repo? 13:21:44 yeah 13:21:49 ok 13:22:20 ok that's all from me 13:23:02 * GeKo is good as well 13:23:17 I have a question 13:23:20 hiro: i'll update you how i'm doing with collector in our next sync, have some things to see with you 13:23:43 go ahead 4xy0m 13:24:48 There is something which is unclear for me which is the behavior of the parser on error like the specification is saying to not enforce rules to support updates but in that's case what to do if for instance a line appear twice when it should appear only once or when a date is not a date ? 13:25:06 * There is something which is unclear for me which is the behavior of the parser on error like the specification is saying to not enforce rules to support future version but in that's case what to do if for instance a line appear twice when it should appear only once or when a date is not a date ? 13:25:43 I think at the moment we emit a log warning and can decide if to ingest the faulty descriptor or not 13:26:17 I think for example collector rarely discards descriptors, but other services are more strict 13:26:34 there is a balance between wanting to know some node is emitting faulty descriptors and do not wanting to ingest those data 13:27:56 Like the current parser is throwing an exception if any parsing error is encounter for instance so should i keep this design ? 13:28:08 yes 13:28:27 I think that approach is still valid 13:29:09 Maybe i can do a "relaxed mode" in order to ignore error if there is ? 13:30:33 yeah but it is better to have a way to chose if we want to discard or ingest the descriptor for example 13:31:38 Like if there is an error i return the error along the parsed descriptor ? 13:31:51 yeah 13:32:10 so that it is still possible to save it if that's what one wants to do 13:32:24 Okok thanks ! 13:32:41 no worries 13:32:56 oook! if everyone is groot we can end the meeting 13:33:16 * juga is good 13:33:27 i am groot 13:33:39 oook !! 13:33:42 #endmeeting