15:58:43 <GeKo> #startmeeting network-health 2024-02-05
15:58:43 <MeetBot> Meeting started Mon Feb  5 15:58:43 2024 UTC.  The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:43 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:47 <GeKo> hello!
15:58:48 <juga> o/
15:59:01 <GeKo> we have a pad over at the usual place: https://pad.riseup.net/p/tor-nethealthteam-2023-keep
15:59:39 <GeKo> please add your items and mark stuff as bold if you want to talk about
16:01:07 <hiro> o/
16:03:37 <GeKo> alright
16:03:56 <GeKo> nothing else stands out, very nice
16:04:00 <matt[m]> o/
16:04:13 <GeKo> ggus: et al. we'll have out monthly bbb sync tomorrow
16:04:19 <GeKo> at 1600utc, just as a fyi
16:04:33 <GeKo> so we don't need to bring up any s112 related
16:04:40 <GeKo> items today
16:04:53 <GeKo> *monthly s112 bbb
16:04:59 <GeKo> matt[m]: hi
16:05:03 <GeKo> how are things going?
16:05:34 <ggus> GeKo: ack!
16:05:46 <matt[m]> I have 0.3.1 ready with the fixes planned for this week, gonna open a MR once 0.3.0 is merged
16:05:59 <hiro> ok going to review 0.3.0 before the end of day
16:06:05 <hiro> sorry for keeping you waiting
16:06:20 <matt[m]> hiro: thanks! no worries
16:06:40 <matt[m]> btw about that vm metrics thing that we were discussing last week
16:07:14 <matt[m]> is that going to require auth in the future? I thought that we could simply return a 302 to the instance if it's going to be open in the future
16:08:21 <hiro> oh no the idea is that we keep VM on the same machine as the api
16:08:23 <hiro> and the DB
16:08:33 <hiro> well the DB we might have to see... but VM I think is doable
16:10:02 <matt[m]> I think that right now the APIs are having issues proxying because I'm first issuing a request to VM and then I'm streaming that request back to the user, which means that the entire request data is kept in memory before being sent back to the user
16:11:16 <matt[m]> If VM is going to be public I think we could solve this by simply returning a 302 to VM so that the client is going to immediately receive the stream of data from VM and we don't have to do the heavy lifting with the APIs
16:11:45 <matt[m]> Otherwise we'd have to think of something else for this particular case
16:11:57 <hiro> uhm so I think the only issue with VM being pblic is that people query VM directly and they kill our service
16:12:39 <hiro> so I am not sure we can make it public, or not right now, but we might think about it...
16:12:43 <matt[m]> right
16:13:24 <GeKo> i wonder whether it would be helpful to have a ticket or something where we'd collect pros/cons to different options
16:13:42 <hiro> yeah we can have an issue in the api repository
16:13:53 <hiro> I'll open it before I review the MR
16:14:02 <matt[m]> +1
16:14:09 <GeKo> thanks
16:15:10 <GeKo> hiro: so, the onionoo issue...
16:15:31 <GeKo> it seems we have no easy way to get good first_seen dates back?
16:15:54 <hiro> well, we could look at the bandwidth history
16:16:00 <GeKo> yeah
16:16:13 <GeKo> that's a non-easy option in my opinion :)
16:16:29 <GeKo> compared to copying good out dirs over etc.
16:17:01 <GeKo> i am not sure whether the bw history is consensus-based, though
16:17:09 <hiro> no it is not
16:17:16 <GeKo> i suspect we are already collecting bw history data once we are running our relay
16:17:23 <hiro> if a relay was offline for a year we would still have history
16:17:39 <GeKo> well, that's fine for first_seen
16:17:45 <hiro> yeah
16:17:56 <GeKo> i was more thinking about relays not being in the consensus until X
16:18:02 <GeKo> first_seen would start at X
16:18:11 <GeKo> while bw history probably before X
16:18:19 <hiro> unless we want the first seen to be a consensus_based field, exactly
16:18:39 <GeKo> so first_seen would start to mean something different to what the spec is saying
16:18:43 <GeKo> at least for some time
16:18:52 <GeKo> until we switch back to the old model
16:19:15 <GeKo> maybe we can do it just to "reset" state
16:19:27 <hiro> uhm
16:19:47 <hiro> or maybe we could announce what happened
16:20:08 <GeKo> well, that to
16:20:09 <hiro> and we live with that
16:20:31 <GeKo> for the old relays, sure
16:20:58 <GeKo> but we could treat new ones like they are supposed to be treated according to the spec
16:21:13 <GeKo> once the "old" ones are "reset"
16:21:36 <GeKo> like i would not keep just using the bw history from now on
16:21:53 <GeKo> as the new status quo
16:22:07 <hiro> ah so you want to reset the old ones?
16:22:15 <GeKo> i thought so
16:22:16 <hiro> I meant that we do a post mortem so to speak
16:22:46 <GeKo> and would go with bw history from now on?
16:22:51 <hiro> nono
16:23:04 <hiro> we just accept that a number of relays will have the first_seen date "wrong"
16:23:25 <GeKo> i think that's not so easy
16:23:33 <GeKo> it messes up my bad-relay work to begin with
16:23:41 <hiro> ah I see
16:23:45 <GeKo> and folks keep showing up wondering what's up
16:24:06 <hiro> then yeah we do the reset for the relays that got the first_seen date on the 10th of January
16:24:08 <GeKo> i think we need some kind of fix for the current situation
16:24:21 <hiro> but we do that in text basically
16:24:21 <GeKo> and 29th of january
16:24:26 <hiro> without changing the app
16:24:34 <GeKo> yeah
16:24:37 <GeKo> that's fine
16:24:44 <hiro> we do a script to read the two documents and make the cahnge in the status
16:24:47 <GeKo> a bit hack-ish but still
16:24:53 <GeKo> yep
16:25:02 <hiro> yep let's do it this week
16:25:05 <hiro> I'll open the issue
16:25:05 <GeKo> +1
16:25:09 <GeKo> thanks
16:25:10 <hiro> and follow up on that
16:25:20 <GeKo> i'll still want to understand what's going on here
16:25:28 <GeKo> so i'll try another couple of hours tomorrow
16:26:16 <GeKo> because i fear this might happen again as it did on jan 29th
16:26:29 <GeKo> and there is really weird shit going on with bridges :(
16:26:52 <GeKo> anyway, that's all from my side
16:26:59 <GeKo> do we have anything else for today?
16:27:07 * juga is good
16:27:09 <GeKo> ggus: you good?
16:27:28 <matt[m]> * matt is good
16:28:18 <GeKo> hiro: anything else from your side?
16:28:41 * hiro is groot
16:28:59 <ggus> GeKo: a quick thing
16:29:05 <GeKo> sure
16:29:16 <ggus> GeKo: pavel announced the 0.4.7.x EOL on social media last week
16:29:28 <GeKo> good, good
16:29:37 <GeKo> what does social media means here?
16:29:47 <GeKo> x? something else?
16:29:51 <ggus> on mastodon: https://mastodon.social/@torproject/111858473454854394
16:30:05 <ggus> x/twitter: https://twitter.com/torproject/status/1753176545525658104
16:30:25 <GeKo> kk
16:30:43 <ggus> and reddit
16:30:49 <GeKo> so we are good here and can get the real work going once i am back?
16:30:56 <ggus> correct!
16:31:01 <GeKo> awesome
16:31:10 <ggus> i pinned your topic on the forum
16:31:26 <GeKo> hiro: wanna pick up next week's nh meeting facilitation?
16:31:31 <GeKo> i'll be out
16:31:39 <GeKo> ggus: thanks!
16:31:39 <hiro> sounds good
16:31:46 <GeKo> great
16:32:33 <GeKo> alright folks
16:32:43 <GeKo> it seems we are done for today/this week
16:32:49 <GeKo> thanks everyone and have a nice week!
16:32:52 <GeKo> #endmeeting