15:59:35 <GeKo> #startmeeting network-health 09/18/2023
15:59:35 <MeetBot> Meeting started Mon Sep 18 15:59:35 2023 UTC.  The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:35 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:59:53 <GeKo> aaaaand we have a pad, as usual: https://pad.riseup.net/p/tor-nethealthteam-2023-keep
15:59:54 <mattrighetti[m]> o/
15:59:58 <juga> o/
16:00:03 <hiro> o/
16:00:09 <GeKo> i see folks have already added stuff, nice, nice
16:00:29 <GeKo> ggus: you around today?
16:00:39 <GeKo> (if not, that's cool too, we can chat on wed)
16:02:47 <GeKo> okay
16:03:03 <GeKo> i have only one item we should think a bit about
16:03:14 <GeKo> https://gitlab.torproject.org/tpo/network-health/metrics/exit-scanner/-/issues/40010
16:03:27 <GeKo> it turns out we got our tordnsel service busted
16:03:36 <GeKo> and there are a bunch of pieces to that
16:03:52 <GeKo> one is that we addressed a s61 audit issue in exitmap
16:04:00 <juga> ops
16:04:05 <GeKo> which we made sure works with out exitmap scanning efforts
16:04:17 <GeKo> but not with the tordnsel setup we currently have
16:04:40 <GeKo> and the second piece is that we pull exitmap main automatically for the exit-scanner
16:04:52 <GeKo> hiro: do you know why we follow main here?
16:05:16 <hiro> we can follow another branch if we wanted
16:05:17 <GeKo> i mean, we find issues that way, which is nice
16:05:21 <hiro> or stop the automatic pulling
16:05:45 <GeKo> but i am not sure whether we would want to follow whatever got pushed to exitmap
16:05:55 <GeKo> i think pullung for the exit-scanner is good
16:06:07 <GeKo> but i am not sure whether we should do that for exitmap as well
16:06:27 <hiro> yeah we can remove that and do it manually
16:06:39 <GeKo> on the other hand we can just fix that particular issue and move on with our lives
16:06:48 <hiro> unless we want to follow another branch which we can call like "production" or "deployed"
16:07:29 <GeKo> phw did some tags for exitmap a while back
16:07:38 <GeKo> probably as kind of a release or something
16:08:01 <GeKo> we could do so as well and then just pick up the latest tag via puppet or manually
16:08:12 <GeKo> i have not strong opinions about that, though
16:08:16 <GeKo> *no
16:10:05 <GeKo> hiro: okay, could you take off exitmap's auto-fetches from puppet?
16:10:07 <hiro> uhm tag change every time a new one is created .. I am not faimiliar if the vcs repo in puppet does that easily
16:10:18 <GeKo> that's fine
16:10:27 <hiro> the easiest would be a branch or just off the auto pull
16:10:35 <juga> GeKo: not sure which directories exit scanner uses, but maybe puppet could create the needed dirs with the correct permissions
16:10:37 <GeKo> imo we don't need to have a fancy autofetch feature for the exitmap part
16:10:54 <GeKo> juga: yeah, that would be an option, too
16:11:24 <GeKo> it's a bit tricky, though as exitmap in the tordnsel context uses /tmp for part of the runs
16:11:56 <juga> and creating one upper extra dir inside /tmp?
16:12:12 <GeKo> so, i guess we might need to have an exit-scanner patch for that part anyway to have the exitmap datadir somewhere more reasonable
16:12:22 <GeKo> yeah
16:12:28 <juga> ic
16:13:09 <GeKo> i gonna think about this a bit more as having this actually properly fixed on the machine would be nice, too
16:13:55 <juga> k
16:14:17 <GeKo> hiro: thanks
16:14:41 <mattrighetti[m]> hiro: can we deploy the latest api too?
16:14:51 <GeKo> that's all from my side
16:15:01 <GeKo> what else do we have for today?
16:15:10 <GeKo> ah, okay. mattrighetti[m] go ahead :)
16:15:10 <hiro> autopulling is off :)
16:15:15 <GeKo> <3
16:15:24 <hiro> sure @mattrighetti[m] I'll do it
16:15:28 <GeKo> then let me just revert to a previous commit for now
16:15:53 <mattrighetti[m]> hiro: Thanks!
16:16:08 <juga> ah, rishad told me can't be here today
16:17:22 <mattrighetti[m]> That’s all from me :)
16:17:32 <GeKo> juga: that's fine.
16:17:50 <GeKo> hiro: okay, i checked out a supposedly working commit for exitmap
16:18:00 <GeKo> does check/tordnsel fix itself now?
16:18:10 <GeKo> or do i need to kick it somehow
16:18:32 <hiro> no you need to restart the service
16:18:36 <hiro> let me do it
16:20:44 <GeKo> k
16:20:51 <juga> ah, hiro, GeKo, is there already any documentation for the new db?, asking cause maybe i could start contributing to it instead of opening issues with things to document
16:20:58 <GeKo> how is sponsor112 work going?
16:21:26 <hiro> restarted
16:21:37 <GeKo> i think right now it's only "in the tickets" and a bit of text on the wiki
16:21:47 <GeKo> thanks
16:22:07 <juga> GeKo: hmm, and which is the wiki?
16:22:19 <hiro> @juga: only for victoriametrics https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/blob/main/METRICS.md?ref_type=heads
16:22:24 <hiro> not yet for the sql tables
16:22:43 <juga> thx hiro
16:23:44 <GeKo> as to s112 for me: i worked on o2.2 collecting anf evaluating past network-health proposals last week and will continue doing so most of this week
16:24:05 <GeKo> (including meeting with ggus and ahf to sync about this topic)
16:24:34 <GeKo> does anyone feel blocked on anything, or are we good?
16:24:48 <juga> sponsor112: learning about json with postgresql... trying to avoid to create scripts in python that couldn't run directly in grafana
16:25:04 <juga> so far just learning/exploring possibilities
16:25:11 <GeKo> hiro: i guess for the jetty update, we might want to start with metrics-base and include that in all the projects where needed... :(
16:25:27 <GeKo> juga: sounds good!
16:26:58 <hiro> @GeKo sounds good
16:27:10 <hiro> maybe I was too optimistic and was tried with too recent versions
16:27:18 <hiro> s/tried/trying
16:27:36 <GeKo> heh, yeah. :)
16:27:44 <GeKo> one can hope, though ;)
16:27:53 <GeKo> alright anything else for today?
16:28:10 * juga is good
16:28:50 * hiro is groot
16:28:53 <GeKo> hearing nothing...
16:28:55 <GeKo> thanks folks
16:28:59 <GeKo> have a nice week!
16:29:00 <hiro> ciao ciao
16:29:02 <GeKo> #endmeeting