15:59:16 #startmeeting network-health 06/12/2023 15:59:16 Meeting started Mon Jun 12 15:59:16 2023 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:16 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:22 alright, let's do it 15:59:29 o/ 15:59:37 https://pad.riseup.net/p/tor-nethealthteam-2023-keep is our pad 15:59:56 just as a note: we'll skip the s112 stuff today as we have our bbb sync tomorrow 16:00:00 at 1800 utc 16:00:08 juga: hiro: ggus: ^ 16:00:09 hi! 16:00:13 ack 16:00:19 so what else did we have... 16:00:53 Hola 16:00:54 one item i had i already covered 16:00:59 o/ 16:01:02 o. 16:01:04 o/ 16:01:12 I need to fill the pad 16:01:21 been fighting a little bug on victoriametrics 16:01:22 ggus: hiro: it seems we are on the hook for an all hands session next week on wed 16:01:28 hey there, i hope i got in time 16:01:31 do i see that right? 16:01:39 RishadBaniya[m]: yup 16:01:39 RishadBaniya[m]: you did, all is good 16:01:43 Will update the pad later 16:01:43 but most of my week would be to work on the metricsdb-01.tpo deployment 16:01:47 GeKo already? 16:01:56 I thought we had more time for a show and tell 16:02:06 2023-06-21: Combating Malicious Relays, presenters Georg, Hiro, Gus 16:02:34 i mean we can talk to pavel if that's unrealistic 16:02:57 but if not we should likely get together some time this week to do some brainstorming maybe? 16:04:03 uhm ok I think it is doable but would have preferred more time 16:05:12 ggus: what do you think? 16:06:11 while ggus is pondering we can move on 16:06:27 more time would be better 16:06:28 the reason is so that I can get the deployment this week without thinking about the presentation 16:06:58 okay 16:07:09 i can mail pavel so we can move things around 16:07:19 2 weeks later? 16:07:53 which would be july 5 16:08:02 wfm 16:08:23 ok! sounds good 16:08:43 great 16:08:46 idk if this is the right place to ask the question, but are these constraints enough to consider while creating circuits for partition checking tool https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/path-spec.txt#L303 16:09:58 RishadBaniya[m]: i think the first "-" items are good 16:10:20 agree 16:10:55 any other questions/topics to talk about? 16:11:04 how is gsoc going in general? 16:11:12 mattrighetti[m]: RishadBaniya[m]: you need help with anything? 16:11:44 All good here 16:12:25 great 16:12:37 Will have some endpoints ready to test by the end of the week hopefully 16:12:46 well, tons of time spent on peeling abstractions 16:12:52 it's fun tbh 16:13:13 nice 16:13:40 i wanted to know your thoughts on using graph database for storing the output 16:14:06 RishadBaniya[m]: i think that'd be great, but not sure we'll have time 16:14:26 on a quick search, i also didn't find a rust implementation that looks stable 16:14:46 maybe we can start with a DBRM, and see later on 16:14:52 *relational database 16:15:36 sounds good? 16:15:52 im going all in this week, as i have complete holidays, should i research more? 16:15:59 on what other options 16:16:02 can i explore further? 16:16:18 ok, dedicate a few hours maybe :) 16:16:47 you have any opinions on this GeKo? 16:16:50 nope 16:16:52 :) 16:16:59 fine 16:17:32 RishadBaniya[m]: i can add in other later, what i found about graph dbs and rust (not much) 16:17:37 ggus: i have one item for you: to check out the thread on dir-auth@ 16:17:38 to an issue/wiki 16:17:51 i think in particular alex's last mail is relevant... 16:18:02 juga: sounds good, thanks 16:18:29 k, i'm still catching up my emails from last week 16:18:34 ggus: which reminds me that we should probably sync some time this week as a bunch of things have piled up i guess 16:18:41 yup! 16:19:15 let's do the 2 person doodle outside this meeting... 16:19:22 anything else for today? 16:19:30 * juga is good 16:19:38 all good! 16:19:56 reminder for the folks working on sponsor112: we'll have our monthly bbb sync tomorrow 1800 utc 16:20:09 thanks for the reminder! 16:20:23 hiro: all good? 16:20:38 good 16:21:04 i had one question, i almost forgot to add 16:21:23 RishadBaniya[m]: go ahead 16:21:26 nick had mentioned that calling timely_netdir 16:21:29 and storing the output 16:21:31 for long period of time 16:21:36 leads to excessive memory usage 16:21:51 yup 16:22:01 and this partition checking tool 16:22:06 seems to hold this for long period of time 16:22:10 it seems right? 16:22:24 so how does this affect 16:22:26 as i interpreted, i think it should be call every hour 16:22:28 the tool that we're building 16:23:00 or have some event listener (if possible) that get notified on netdir updates 16:23:14 that, yes 16:23:36 or we can just have it run every X hours to begin with 16:23:44 but i don't know much about arti/rust, so you can try one of those approaches, and we'll see how it performs 16:24:16 we can show arti people some concrete piece of code too, and ask them what they think 16:24:36 +1 16:24:49 yeah there is a method called events() that returns stream of DirEvent, so as of right now the only way i could find was to get the updated netdir and consider influx of new relays and new descriptors is by listening on that stream and updating our NetDir when we receive some new DirEvent 16:25:06 Rishad Baniya: if you need any kind of help with rust you can ping me, I’ll try to help 16:25:32 thanks mattrighetti , sure! 16:25:38 RishadBaniya[m]: that way looks good to me 16:26:21 *sounds 16:26:54 okay, folks. i think we can close the meeting for this week. thanks everyone for joining and have a nice week 16:26:58 #endmeeting