13:00:34 <hiro> #startmeeting network-health 2024-11-25
13:00:34 <MeetBot> Meeting started Mon Nov 25 13:00:34 2024 UTC.  The chair is hiro. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:34 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:00:41 <GeKo> hi!
13:01:01 <gaba> hi
13:01:07 <hiro> o/ gaba
13:01:15 <sarthikg[m]> o/
13:02:35 <hiro> GeKo: I need to review all the tagtor issues but I think we should be done, I think I'll make an issue for you to review for next week p112 meeting
13:02:48 <GeKo> thanks
13:03:07 <GeKo> could you deploy the stuff you think fixing the remaining p112 part?
13:03:21 <GeKo> i'd like to play a bit with it then
13:03:26 <ggus> o/
13:03:36 <hiro> yep it is deployed as we merge it into main
13:03:50 <hiro> tagtor is CI integrated
13:04:13 <hiro> anything that is in main is deployed via puppet
13:04:18 <hiro> o/ ggus
13:04:24 <juga> nice
13:05:06 <GeKo> hiro: okay. so, let me know then when you are done with your round and i take another look at what we got
13:05:15 <hiro> sure!
13:05:51 <hiro> so today I was talking with sarthikg[m] about https://gitlab.torproject.org/tpo/network-health/metrics/metrics-website/-/issues/1 and he is thinking instead that we could use the api (network-status-api) and use soimething in node instead on the backend.
13:06:03 <hiro> @sarthikg[m] would you like to talk about your idea?
13:07:24 <juga> we can also discuss it in the issue
13:07:36 <hiro> yep that too
13:08:06 <sarthikg[m]> yeah. so I was thinking that if the metrics website we are building is more interactive, as in will require more javascript, then it makes more sense to use a javascript framework to build it, since it will make the code more maintainable over time when compared with writing the same amount of javascript in jinja.
13:08:17 <sarthikg[m]> i'll replicate the same in the issue as well
13:08:35 <hiro> thanks @sarthikg[m]
13:08:48 <juga> sarthikg[m]: yeah, makes sense
13:09:05 <hiro> the problem is that none of us except @sarthikg[m] speaks much javascript
13:09:22 <GeKo> well i do from browser land
13:09:23 <juga> yep, that might be the main issue
13:09:28 <juga> oh
13:09:29 <GeKo> but i am not a node fan :)
13:09:58 <juga> django has also some some automatic js for class views, but we can see in detail in the issue
13:09:59 <hiro> oh right @GeKo ... I speak only plain js
13:10:34 <GeKo> do we have requirements written up somewhere
13:10:41 <hiro> the pro of this is that we could use nsa as the main backend, and spend time into developing that
13:10:49 <GeKo> so we can see why we would need to go the js route?
13:10:59 <hiro> @sarthikg[m] needs  to add that to the issue
13:11:22 <hiro> so we can discuss the two options
13:11:24 <GeKo> or is it just a "we feel we might want to be more interactive at some point in the future and thus it would be smart to already start now with js"
13:12:08 <sarthikg[m]> hiro: additionally, there's js frameworks now which builds the webpage on the server before shipping to the client, which means none to little javascript is actually present in the final page
13:12:27 <gaba> if node.js is used or a js framework arent we excluding many people that disable js to use the site? i wonder how many relay operators that would be
13:13:06 <GeKo> gaba: that's a different thing and is not necessary
13:13:12 <GeKo> what sarthikg[m] said
13:13:12 <hiro> @gaba it will be used in the backend if so, there won't be js in the frontend
13:13:23 <gaba> ah ok
13:13:30 <juga> for the backend part, insead of  node js, i'd rather use python and retrieve the data from nsa instead db, but we can see more in the issue..
13:13:30 <hiro> and our current metrics website already has some js (backbone)
13:14:26 <hiro> ok @sarthikg[m] so please update the issue with everything you were considering and the different framework proposed
13:14:48 <GeKo> +1
13:14:52 <sarthikg[m]> juga: we might not even need a backend layer. js could call api's (nsa) on the server, and render the page, and ship it to the client.
13:15:02 <sarthikg[m]> hiro: sure, will do!
13:15:16 <juga> sarthikg[m]: ic
13:15:20 <juga> *i see
13:15:49 <hiro> anyway: let'
13:15:55 <hiro> s discuss on the issue
13:16:43 <hiro> so we can evaluate the options on the table
13:17:00 <juga> yeah, interesting issue in any case ;)
13:17:51 <juga> (from engineering point of view)
13:19:06 <hiro> ok I have to finish MR 100 @GeKo for descriptorParser and then restart ingesting the data. Do you want to do that this week or is it a bad moment?
13:19:33 <hiro> given any analysis you are currently working on?
13:19:36 <GeKo> hrm
13:19:44 <GeKo> yeah, i think this week might not be that good
13:19:58 <GeKo> i need to think about it
13:20:02 <hiro> ok
13:20:12 <juga> hiro: do you know how long it could take to ingest several months?
13:20:35 <hiro> uhm I am not sure
13:21:03 <hiro> I have setup this in the script to go back a number of days every time the parser would be started
13:21:10 <juga> ok, no problem, just thinking that if it takes less than 1 day could work
13:21:17 <hiro> uhm no
13:21:23 <hiro> I do not think so
13:21:28 <juga> ok
13:21:44 <hiro> one thing I could do tho, is run the MR on my computer and send the data to  clickhouse
13:22:05 <juga> interesting...
13:22:09 <hiro> and both you and geko could use that to see if we like the data it is creating
13:22:20 <juga> sounds good to me
13:22:44 <juga> if that doesn't add more complexity on your side
13:23:09 <hiro> I do not think so because I think it uses the same syntax
13:23:24 <hiro> for sure it uses the same driver in java
13:23:27 <juga> awesome
13:23:57 <GeKo> hiro: sure!
13:24:46 <hiro> @juga @GeKo is there anything else on your side? am I blocking any of you in any way with soem issue?
13:25:05 <juga> fine from my side
13:25:14 <juga> i mean, not blocking me
13:25:20 <juga> i've a question for GeKo though
13:25:28 <juga> on what to prioritize now that i'm probably done with the upload web server issue
13:25:57 <GeKo> the final metric for o1.2, that is the uptime piece that is missing
13:26:07 <juga> ok
13:26:31 <GeKo> i hope i can got back to bw inflation after this week
13:26:31 <juga> i'll focus on that
13:26:41 <GeKo> and we'll see whether we can/need more to work on that then
13:26:49 <juga> sounds good
13:26:53 <GeKo> but, yes, the uptime one is the most important right now
13:27:08 <juga> ok, will prioritize that this week
13:27:38 <hiro> <3
13:29:01 <hiro> @ggus is there anything from your side? Do you need help preparing the meetup for december?
13:29:11 <ggus> hiro: yes, we need to find a new date
13:29:18 <ggus> november is/was a busy month
13:29:54 <ggus> wdyt of december 7th?
13:30:09 <hiro> sounds good to me
13:30:24 <hiro> I was going to suggest the 14th if that'
13:30:26 <hiro> s too close
13:30:29 <hiro> but otherwise that's ok
13:30:44 <ggus> i have a local event on 14th :S
13:31:18 <hiro> 21st would work too but it would be very close to ccc... although not everyone goes to ccc from our community
13:31:40 <ggus> and maybe it's too late
13:31:54 <hiro> yep ok lets do 7th then
13:32:03 <ggus> cool! i'll create a pad for us
13:32:17 <hiro> \o/
13:32:30 <hiro> anything else?
13:32:34 <ggus> the last meetup of 2024! \o/
13:32:42 * juga is good
13:32:59 <hiro> intense year 2024
13:33:13 <ggus> exhausting year
13:33:28 <hiro> anyways
13:33:42 * hiro is groot
13:33:46 <GeKo> all good here
13:34:38 <hiro> oooook! thank you everyone
13:34:41 <hiro> #endmeeting