15:59:45 #startmeeting network-health 2024-01-22 15:59:45 Meeting started Mon Jan 22 15:59:45 2024 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:45 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:52 o/ 16:00:07 we have our pad 16:00:22 over at https://pad.riseup.net/p/tor-nethealthteam-2023-keep 16:00:37 please add items to our agenda for today if you have not yet done so 16:01:03 ggus: juga: 16:01:42 mattrighetti[m]: so, hiro and i had some onionoo ticket triage sprint last week 16:01:52 and we just dumped a bunch of tickets over to nsa 16:01:58 hope you don't mind :p 16:02:09 some of these will need some work on the parser side tho 16:02:14 yeah 16:02:32 but i guess they give a good overview about how nsa could evolve 16:02:34 over time 16:02:42 Yep, I saw you moved a bunch of issues on nsa :) cool! Most of them are new requested features I see 16:02:46 even though it doesn't have to 16:02:51 yes, that's right 16:03:00 it's future-work imo 16:03:29 HI 16:03:34 HI 16:03:35 I was thinking, since @mattrighetti[m] is working on a 0.3 version, that we could tag the ones that can be implemented already and leave the ones that need parser work out 16:03:57 sure,sure 16:04:33 Version 3 is ready to be reviews, it closes 3-4 issues I don't quite remember the exact number 16:04:49 ah ok @mattrighetti[m] , I'll see that MR then 16:05:16 This week I'm going to work on some others, like the victoria metrics data that is not returning stuff right now :/ 16:05:17 hiro: Did anything change for victoria metrics? 16:05:18 well, fine for a 0.4 or something else 16:05:35 I'll create like a ready-to-code tag or a need parser tag so you can skim through those issues anyways 16:05:46 and see what you feel like implementing 16:06:00 makes sense, thanks! 16:08:38 mattrighetti[m]: anything else from your side you need help with etc.? 16:08:55 ggus: you around by chance? 16:08:58 hiro: Did anything change for victoria metrics? 16:09:13 uhm I do not think so @mattrighetti[m] 16:09:21 I wonder if it is running properly 16:09:26 let me check real quick 16:09:46 Hi! 16:09:53 I’m around now 16:10:00 Yeah, I can't seem to make nsa return stuff from it, but I did not test by using curl directly against vm so... 16:10:19 wow a Gus2 16:10:30 probably an imposter :) 16:10:57 i'm getting stuff from victoria metrics right now, but querying bandwidth files and network status 16:11:12 (in case it's the same victoria metrics source) 16:11:26 @mattrighetti[m] I see some errors in the logs... if you send me the query I can check ift 16:11:34 s/ift/it 16:11:36 Very likely an imposter! 16:12:01 juga, hiro: alright, then it must be something with the nsapi proxy then 16:12:30 new issue popping up eheh 16:13:09 mattrighetti[m]: that's how we roll ;) 16:13:25 Gus2: okay, what first? 16:13:30 the meetup? 16:13:38 this year resolution tho is less issues w metrics infra 16:13:54 going to open a ticket as soon as I understand what's wrong with it, other than that I'm good! 16:14:01 nice 16:14:01 thanks @mattrighetti[m] 16:14:18 Gus2: looking at the pad, your agenda looks good to me 16:14:34 GeKo: yeah, i announced the meetup on tor-relays, forum, Reddit, and i will ask comms to announce on tor socials 16:14:41 +1 16:15:09 GeKo: should we include something about the policies in general? 16:15:26 we could explain this new process (again) 16:15:29 can't hurt imo 16:15:45 Ok! 16:15:56 i think we did not send an explicit mail about that to tor-relays@ yet, right? 16:16:01 Now that we even have a website with all the policies 16:16:02 so, folks might not be aware of that 16:16:06 yeah 16:16:14 good stuff! 16:16:26 GeKo: about how to submit proposals? I think we did. And we also had a meetup talking about it 16:18:01 dunno, for some reason i always feel we missed a final announcement or something 16:18:01 bye Gus2 16:18:10 it was a nice fellow! 16:18:22 it was a chatpgt bot 16:18:39 good one! 16:18:44 * arma2 starts to wonder what this means for arma2 16:18:45 GeKo: ok! we can do another announcement 16:18:46 felt like the real ggus 16:18:58 :) 16:19:08 ggus: i see your "Process for new policies and proposals for the Tor relay operator community" 16:19:14 from june 16:19:31 might be good enough 16:19:45 but a reminder during the meet-up can't hurt imo 16:20:22 ggus: okay, eol work 16:20:28 it seems it's time again :) :( 16:21:06 why you want to remove all our precious bridges :( 16:21:09 i think we can be smarter this time and don't need to kick out all affected relays manually just to leave some of them in at the end once they fixed their stuff 16:21:20 no, i want them to upgrade :) 16:21:37 but otherwise the process will be much the same... 16:22:34 GeKo: hm, i didn't understand the difference 16:22:55 ggus: i'll be out week 7, so i would start to collect eol info in the week of feb 19 16:23:10 in the process? 16:23:19 yes 16:23:43 this time we might just get the relays rejected at the dirauth level directly 16:23:51 if they have not upgraded 16:24:01 by getting a tor release out with the respective patch 16:24:09 ah, i see 16:24:14 which is ready and just sitting around for a point release 16:24:15 sounds good 16:25:17 ggus: starting the work officially on 2024-02-19 sounds good for you? 16:25:27 https://metrics.torproject.org/rs.html#aggregate/all/version:0.4.7 16:25:32 wanna do some social media upgrade outreach before that? 16:25:46 yeah, it's quite a lot of relays and bridges still on 0.4.7... 16:25:48 GeKo: yes, feb 19 works for me 16:25:55 okay 16:25:57 we can announce on social before that 16:26:04 thanks, please do 16:26:25 alright 16:26:41 do we have anything else we should talk about today? 16:26:55 * juga is good 16:26:59 * ggus is good 16:27:14 * matt is good 16:27:19 hiro: i just saw https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/72#note_2986617 16:27:27 yeah 16:27:45 i wonder whether it would be useful if you tested what we currently have in !49 and see whether the algo you have right now is an improvement 16:27:54 without me having finished the review 16:28:19 because if we see that does not solve the issue we might need to get back to the drawing board 16:28:20 uhm 16:28:30 and could save us some review and rebase time 16:28:52 you mean like a yolo deploy? 16:28:54 (or some better rebased version of !49, that is) 16:28:56 yeah 16:29:12 and see whether this fixes #72 theoretically 16:29:27 uhm 16:29:34 i know, right? :) 16:29:44 i am fine if you say "no" 16:29:47 so, I think I can fix what you mentioned for tomorrow 16:29:58 and then open an issue for the more open questions you left 16:30:23 * ggus o/ 16:30:24 I think we need to add a mode in the parser that allow us to process old data 16:30:35 i have not even looked at the family generation code yet, so... 16:30:53 ah! 16:31:09 ok well I do not think the current family generation stuff we have is working anyways 16:31:22 i just spent some time on the status builder as i wanted to get a fresh picture of the whole system working 16:31:40 so I think we can do a merge once the code is "clean-enough"^TM and then open the subsequent issues 16:32:05 what do you think? 16:32:34 uhm 16:32:36 :) 16:33:03 fine with me 16:33:39 let's see where we are at the end of tomorrow? 16:34:03 maybe we feel comfortable by then testing something for #72 16:34:17 yep 16:34:20 sounds good 16:34:25 great 16:34:35 hiro: anything else? 16:34:51 well there is some issue with onionoo-backend-02 which I do not understand 16:34:56 but besides that all groot 16:35:08 is it just -02? 16:35:26 i thought -01 was behaving weird as well from time to time? 16:36:14 uhm I am not sure I understood 01 was sending the correct first-seen time 16:36:18 and 02 wasn't 16:36:37 I haven't checked the status on disk for the reported relays tho 16:37:35 ah, okay 16:37:48 maybe it was indeed just 02 16:38:25 okay 16:38:39 i think that's it for today 16:38:46 thanks everyone and have a nice week 16:38:49 #endmeeting