15:02:18 #startmeeting metrics team 15:02:18 Meeting started Thu Jun 6 15:02:18 2019 UTC. The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:18 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:02:32 should we start with the non-OP related topics? 15:02:43 sounds good 15:02:57 ok 15:03:00 tom's data (karsten) 15:03:20 I downloaded the data and didn't do anything with it yet. I only copied that item here to show that I didn't forget it. 15:03:36 ok 15:03:51 [INFRA INVENTORY] Sysadmin Team 15:03:54 [...] 15:04:03 when do they need this info? 15:04:17 in that link over there 15:04:22 this sounds like documentation i was putting together anyway as part of operation monitoring 15:04:23 the nextcloud one 15:04:24 and why don't they know what of their resources we're using? ;) 15:04:28 but that documentation is not complete 15:04:34 there is not so much to discuss but only to be sure it is understood 15:04:41 irl: what do you mean? 15:04:55 karsten: they think there may be something missing of what they know 15:05:00 i have to know what we have in order to monitor it 15:05:30 the spreadsheet has a column for comments. You can add any other info there 15:06:04 karsten: there may be some amazon resources for example that people are using that anarcat does not know about... I'm guessing 15:06:22 does that makes sense? 15:06:49 there are tpa things, hetzner cloud, aws, otf cloud and aberdeen 15:07:12 I guess we can fill in some rows in that spreadsheet. 15:07:14 is this a spreadsheet just for us? 15:07:21 or is this a template? 15:07:22 or are we the first to use it? 15:07:36 this is for everybody at Tor 15:07:37 i think you might be the first :) 15:07:39 hi 15:07:41 hi! 15:07:42 we are the first to use it :) 15:07:50 we need to add info there 15:07:57 should we edit the spreadsheet on nc? 15:08:04 yes please 15:08:25 i cannot see me doing this until july 15:08:26 want to start with that, irl, and I fill in anything you might have missed? 15:08:35 ah, okay, in that case I can start. 15:08:43 you can do it after the meeting. No need to do it now 15:08:54 (is hetzner cloud not part of tpa?) 15:09:22 anarcat ? 15:09:30 or irl? 15:09:33 tpa does have some stuff in hetzner cloud 15:09:42 but there might be non-tpa hetzner cloud stuff as well! 15:09:47 that's what i want to find out :) 15:09:49 anarcat believes we have a login for it and might manage zero or more vms ourselves 15:09:57 ah. 15:10:02 I don't. 15:10:11 ok, then we have no non-tpa hetzner cloud stuff (: 15:10:14 alright, I'll give that a try after the meeting. 15:10:48 moving on? 15:10:49 all the aws stuff is cloudformation templates in metrics-cloud.git, and the otf cloud stuff is the onionperf instances, and then one instance at aberdeen 15:10:58 so that is actually reasonably easy if that is enough information 15:11:24 basically, what i'm trying to figure out is how much infrastructure TPI/TPO is managing / using 15:11:27 if there's overlap 15:11:38 if there are unfullfilled needs 15:11:50 makes sense. 15:12:07 and how we could plan this collectively in the long term - what belongs to amazon or hetzner or our own hardware (or not) for example 15:12:35 i started by doing a TPA inventory, which is mostly complete, but i figured i might as well get a fuller picture if we're going make new budgets anyways 15:12:56 I'll fill in a couple rows in that spreadsheet and then you tell us if you need more, okay? 15:13:00 i hope that will be useful for all teams as well :) 15:13:03 awesome, thanks! :) 15:13:16 sure, thanks for keeping track of our resources! 15:13:31 moving on: 15:13:32 Creating the agenda for Tor meeting. 15:14:07 I'm currently trying to get things done before all hands and haven't thought much about stockholm yet. 15:14:44 ok. The issue is that this time there is only 3 days 15:14:58 1st days will be team meetings like roadmap building and retrospective 15:15:01 we used to have a table that showed all the sessions and which would run in parallel 15:15:07 is that table now no longer valid? 15:15:10 And there are a lot of sessions that people may want to do. 15:15:24 that table is fine but there is no way that we can put all the sessions there and make a decision 15:15:33 it is first in first serve kind of table for schedule 15:15:45 The link to that schedule is at the top of the pad. 15:16:15 The idea would be for us to add sessions there and then we can merge them and/or make priorities. Before Stockholm we would have a schedule in the table in the wiki 15:16:34 i think as long as we have the roadmapping session for metrics, we do not need other sessions 15:17:37 ok 15:17:50 no other session that you are thinking could be good to have with other people at Tor? 15:18:16 it will be good to meet other tor people. 15:18:19 we would probably need to be in other sessions that are happening 15:18:34 but we wouldn't need to make new sessions, i don't think we have any work that would require that 15:18:38 it's not primarily important to have a session about a specific topic. 15:18:41 ok, sounds good 15:18:50 hi! just arrived 15:19:07 hi acute! 15:19:54 gaba: I'm sorry, but planning sessions for stockholm isn't something I can do right now. 15:20:48 sounds good karsten 15:20:49 no problem 15:21:03 ok. 15:21:14 New data portal 15:21:34 that's gaba's item. 15:22:00 yes, mostly to discuss anything from the mail thread we had. I want to be sure next steps are clar 15:22:21 there was a thread? 15:22:32 You asked me about how the meeting went and I replied 15:22:41 ah, a small thread 15:22:46 hehe 15:22:55 the little-thread 15:23:16 i think that, time permitting, i'll proceed with getting it set up but just use the default theming for now 15:23:29 sounds good 15:23:34 yes, that sounds like a good plan. 15:23:46 maybe that'll help understand the purpose and make a design later. 15:23:49 this might also help to provide context, yeah 15:24:10 cool! 15:24:38 next topic? 15:24:49 ok 15:24:55 Roadmap: how are we doing with the tasks in progress? 15:25:39 shall we go through the in progress items? 15:26:03 yes 15:26:17 please :) 15:26:25 #21378 is pretty much done, except for the part where we'd import tom's archive. 15:26:26 yes please, I'm not able to load it 15:26:40 but everything else is done there. 15:26:53 #29377 is acute's. 15:27:16 (acute: did you try selecting All boards and then once again the metrics roadmap?) 15:27:38 yes, I did 15:28:07 currently checking the coverage, it takes a few seconds 15:28:34 i am still working towards #28322 and also onionperf upgrades but i guess the "in progress" tickets specifically are #30761 #30762 #30763 #30764 #30765 15:28:45 I think the question is mostly whether you're planning to work on this, say, next week, acute. 15:29:09 which is not the question I answered myself above, either. ;) 15:29:17 i think we said that unit test coverage would be done once tests were done with travis ci 15:29:28 on improving/adding tests? yes, definitely 15:29:33 oh, maybe add that to the card, irl? 15:29:59 thanks! 15:30:08 added 15:30:42 so, #29507 has quite some progress with 1 update graph and 1 new graph on metrics.tpo. 15:30:55 the remaining work is on today's agenda. 15:31:24 what about acute's #29375? 15:31:44 also still working on this 15:31:59 * gaba is having some issues with the computer and battery... 15:32:03 this one is done once we have jenkins building the onionperf docs automatically i think 15:32:04 uh oh.. 15:32:05 (just in case i disappear) 15:32:13 then we can have specific tickets for other documentation tasks 15:32:28 okay. 15:32:29 ah, fyi our test coverage now seems to be at 60% (will update the ticket) 15:32:36 neat! 15:32:42 yes, that sounds good 15:33:03 oh, what about #26597? 15:33:17 acute: I think that's yours at the moment, right? 15:33:26 might be easy to clear the on review column. 15:33:50 yep, will take of this ASAP 15:34:02 thanks! 15:34:09 I did not realize I was the reviewer! 15:34:15 surprise! 15:34:19 :) 15:34:20 the dangers of contributing is you also end up reviewing 15:34:27 hehe 15:34:30 usually it's the other way around 15:34:42 heh 15:34:59 anything else related to the roadmap? 15:35:36 if not, should we move on? 15:35:45 yes 15:35:52 gaba: did you want to add #30761 #30762 #30763 #30764 #30765 to in progress? 15:36:09 I just did 15:36:12 excellent 15:36:13 I added them all together 15:36:14 (: 15:36:32 great! 15:36:33 cool 15:36:46 okay, next topic: 15:36:51 Reprocessing OnionPerf tgen/torctl logs (karsten) 15:36:56 first question: 15:36:59 partial download timestamps PARTIAL* vs. multiple .tpf lines 15:37:06 yes! 15:37:31 is this already merged? 15:37:38 the PARTIAL* fields? 15:37:45 no, irl is holding off merging this one 15:37:53 and the ERRORCODE field is merged? 15:38:01 i didn't think it made sense to not have all the same sized measurements in the same tpf file 15:38:12 yes, the ERRORCODE patch is merged 15:38:14 if you want all the smallest measurements, you have to parse all 3 files 15:38:17 which is weird 15:38:36 I'm not sure the design with PARTIAL* fields is perfect, 15:38:46 but it's still 1 line per measurement. 15:39:02 we might add other fields which would then still belong to that measurement. 15:39:19 and after all, we did request a 50k or 1mb or 5mb file in that single measurement. 15:39:28 but! 15:39:36 I didn't mean to discuss this here, necessarily. 15:39:53 how about we discuss this on the tickets? 15:39:57 ok 15:40:00 sounds good 15:40:29 second item: 15:40:30 ERRORCODE and resulting graph 15:40:53 we're still unclear whether the graph is too hard to digest, 15:41:06 but I think we agree that having the ERRORCODE fields in .tpf files would be useful, right? 15:41:30 we could still make our own graphs from that and not put them on the website. 15:41:52 I'm asking because I'd like to reprocess these logs. 15:41:56 I'm a bit behind with the table of descriptions for what each error means 15:42:09 having ERRORCODE fields in the tpf seems entirely reasonable, yes 15:42:20 it's definitely useful to have the ERRORCODE in the *tpf files 15:42:27 okay, cool. 15:42:40 no worries about the descriptions. they will be super useful, but they're also not trivial to write. 15:42:49 and reprocessing logs will take time anyway. 15:43:22 which brings me to the next item: 15:43:25 log file availability 15:43:33 is there an easy way to fetch them? 15:43:56 like, would it be possible to make them available via the webserver? 15:43:59 when we did the work on the persistent onion addresses we made sure to keep the data directory clean of keys 15:44:12 so yes, all the logs should be able to just be made available via the web server 15:44:19 you did that with op-ab. 15:44:26 can you also do that with the other three? 15:44:35 should be able to 15:44:58 that would be great! 15:45:09 I'll take care of the rest. 15:45:46 last item: 15:45:49 -n parameter for SOURCE 15:45:54 thanks for adding that! 15:46:03 if it's not merged yet, I'll use your branch. 15:46:04 glad you find it useful! 15:46:37 alright, that's all about reprocessing OP logs. 15:46:46 next topic comes from the tor-scaling meeting: 15:46:49 New OnionPerf tgen ping model (karsten) 15:47:08 the question was whether we could run a second tgen model which is like ping. 15:47:29 the current model sends a small request and gets a 50k/1m/5m response back. 15:47:35 1 byte download 15:47:42 this new model would send a small request every second and get a small response back. 15:47:49 right. 15:47:59 but logs of those downloads over the same circuit. 15:48:32 are we trying to measure jitter over a circuit? 15:48:41 ok, so it's easy to make a tgen model 15:49:40 so, part of the goal here is to figure out how much effort it would mean to add more models to OP. 15:49:56 there might be other models that would be interesting to measure, 15:50:03 and other measurements might require OP code changes. 15:50:19 the hope here is that we can make these measurements just with a new tgen model. 15:50:34 we could even run this for a short period of time only, not permanently. 15:50:42 and then decide what to do with it. 15:51:13 I guess I could run this on my home server. 15:51:15 ok, so I think we should decide on one new model to try 15:51:30 do you have another model in mind? 15:51:48 this seemed rather simple and easy. 15:51:55 as you mentioned, ping once a second for a minute? 15:52:14 right, or for five minutes, then start over. 15:52:34 the current model starts a new measurement every five minutes, too, right? 15:52:55 so the hard bit is adapting the way the analysis is done I think 15:53:01 yes, right. 15:53:19 for this experiment we could use the logs as input. 15:53:34 for a one-off analysis. 15:54:05 should I create a ticket for this? 15:54:07 there are 5 minute pauses between transfers, yes 15:54:14 where we discuss this more? 15:54:32 sounds great! 15:54:55 awesome. thanks a lot for all your OP work, acute! 15:55:16 thank you for this :) 15:55:24 looks like we're out of topics. 15:55:30 and out of time, too. 15:55:36 unless there's anything else? 15:55:37 perfectly timed 15:55:48 nothing els 15:55:55 nothing from me 15:56:11 next meeting on monday, because we won't have a meeting next thursday or the week after? 15:56:16 ahh 15:56:29 i did not write a time yet in my diary 15:56:32 shall we pick one? 15:56:39 same time? 15:56:44 works for me 15:56:56 karsten: there is nothing for all hands that you need from irl or me? 15:57:19 (other than the topic just discussed...) 15:57:33 did you have a topic on that that disappeared? 15:57:54 yes, cause there was no time 15:57:57 ah! 15:58:03 but now that there may be no meeting bfore :) 15:58:06 i'm bringing it back 15:58:11 there is: on monday. 15:58:20 or we can talk on monday 15:58:21 yes 15:58:28 that's one reason why I thought it would be useful to have that meeting. 15:58:35 great! 15:58:38 yes, let's talk about that on monday. 15:58:45 i can make same time on monday 15:58:50 perfect! 15:59:06 thanks, everyone! have a great evening/day! 15:59:12 o/ 15:59:13 thanks 15:59:18 bye! 15:59:21 #endmeeting