15:01:13 #startmeeting metrics team 15:01:13 Meeting started Thu Aug 15 15:01:13 2019 UTC. The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:13 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:01:21 https://storm.torproject.org/shared/5h1Goax5eNusxjXJ_Ty5Wl7hFR1uqCReUiN8xdlBG8T <- agenda pad 15:01:34 hi! can we talk about funding proposals first? 15:01:38 * karsten didn't send out a meeting reminder this time, glad you made it anyway! 15:01:45 I need to leave in 30 min sharp 15:01:49 sure! 15:02:18 karsten, irl: do you both have a link to each proposal, right? 15:02:29 only the "scaling" one 15:02:51 * irl really thinks we should give the proposals names so we can talk about them *before* we get them submitted 15:02:54 ok. I sent you the one on IPv6 15:03:09 you do not like "the scaling one" as a name :P 15:03:20 what if we apply to two places for different scaling things 15:03:44 ok, i see both proposals now 15:03:45 then it gets converted into the scaling-grant-name proposal 15:04:50 the scaling one is the one that is mostly work for metrics 15:05:12 karsten indicates he has connectivity issues 15:05:14 sorry, got disconnected. 15:05:17 back now. 15:06:18 for the scalability one I would love karsten to read it and comment if ther eis any comment 15:06:23 and we need estimation 15:06:40 what's the timeline for these two? 15:06:49 we also need tickets for scalability tasks but that is independent of this proposal 15:06:52 i only looked at the intro for the scaling one, the rest there are still problems with unless it's been rewritten to match 15:06:53 (I didn't open any links yet.) 15:07:18 the ipv6 one is tricky, i can see exactly what we would need to do there but i don't know if we would have capacity to do it 15:07:24 the scalability one is on rolling basis so we do not have a deadline. We want to get it out of the door soon. 15:07:34 the ipv6 one is September 1st 15:07:52 we would need to work on adding new metrics to extra info descriptors for ipv4/v6 metrics and then archive/visualise them to say whether or not things work 15:08:01 irl: yes, alsmith is working on the rewritten. we have a very good grants writer :) 15:08:04 this is probably the same metrics i suggested in my review of the happy eyeballs proposal 15:08:20 irl: do not worry about capacity for now 15:08:57 if i ignore capacity, i agree with teor4 on basically all the ipv6 stuff we've ever discussed 15:09:05 and the proposal looks good from skimming it 15:09:18 ok 15:09:19 regarding tickets (as far as that's related), I'm blocking on receiving more input on what's needed. 15:09:39 karsten: i do not undertand what you just wrote 15:09:44 sorry. 15:09:51 regarding those tickets that need to be written, 15:10:04 scaling tickets? 15:10:06 I only have a single sentence stating something very general. 15:10:09 yes, those. 15:10:21 I'd need to hear more about the actual questions behind those to write something useful as ticket. 15:10:54 maybe reading the proposal will shed some light on this? 15:11:04 ok. I understood that those are issues already discussed before and that is why they did makes sense. Can you contact mikeperry with any question that needs to be answer to write them? 15:11:55 I think it makes sense for you or irl to write them as they are stuff metrics will do. And Mike is quite over capacity right now with stuff that needs to be finish this month. 15:11:57 I could try, but last thing I hear is that he's focusing on a sponsor thing. 15:12:08 yes, but he can answer some questions 15:12:11 right now there is no urgent scaling task 15:12:14 for metrics 15:12:28 okay, if that's the case, then let's not rush this. 15:12:43 there is no urgent task but we need to move forward on this 15:12:46 i have some tickets for the "alternative reality simulator" on my whiteboard but i didn't put them in trac yet 15:13:20 (diff fast/guard cutoffs and how the aggregate stats of the network change by excluding relays, etc) 15:13:21 gaba: can this wait for another two weeks? 15:13:42 the creation of tickets? 15:13:45 irl: sounds great, happy to take a look once it's on trac. 15:13:52 yes, creating tickets and moving forward there. 15:14:15 this will be more useful with mike's input. 15:14:30 mike may be with a lot of other things until end of september 15:14:37 i do not think we have to wait for mike here 15:14:45 there is a tor/moz meeting next week too 15:14:59 (reminder: i am away tomorrow until the 28th for ccc camp) 15:15:06 ok 15:15:13 (also so is acute) 15:15:38 the most important thing related to scalability is for you to read the proposal and give feedback about it 15:15:47 okay. 15:15:55 irl: are you going to read email? 15:16:07 likely not, i'll be in a field 15:16:15 i can respond to signal messages in an emergency 15:16:27 okay, then we should talk about reviews/releases later on. 15:16:33 sounds good 15:17:45 ok 15:17:57 TorDNSEL/Check replacement ? 15:17:58 what about the ipv6 proposal? 15:18:09 does this need review and feedback, too? 15:18:14 yes 15:18:25 the IPv6 proposal is the one that we are submitting in 2 weeks 15:18:39 ok. 15:18:51 TorDNSEL/Check replacement 15:19:18 (https://lists.torproject.org/pipermail/tor-dev/2019-July/013918.html has some thoughts i had on ipv6, including metrics we want) 15:19:55 great, added to the pad. 15:20:12 so, what's required for #29399? 15:20:36 last week I said it's on our current roadmap. 15:20:41 when does that end? 15:20:42 in stockholm, this task moved futher and futher along the roadmap until it nearly fell off 15:21:02 uh, that is my fault on not following up on this. We really need to move this up in priorities 15:21:14 i found it very hard to say this was a priority above other things we have on the roadmap 15:22:03 why? 15:22:16 because other things were either sponsor work or blocking other teams 15:22:29 this is an emergency that we've manufactured for ourselves 15:22:58 i would rather compromise on running an older debian for a few months than have another team fail to deliver for a sponsor 15:22:59 mmm, i'm looking at the roadmap in trello 15:23:03 which one is sponsor work? 15:23:52 in my decisions i treated scaling as "above non-sponsor work" 15:24:00 also we have sponsor30 and sponsor28 15:24:16 yes, scaling is priority 15:24:27 right, so this is how it ended up at the end of the roadmap 15:24:36 it's still included but right now no effort is being made on it 15:24:37 there is a few things on sponsor 30 (that still technically didn't start yet) 15:24:46 so, the reason we're discussing tordnsel now is that buster got stable, right? 15:24:58 i believe so 15:25:00 and s28 there is also a few things but we can move this after this other one. 15:25:24 if that's the case, it's a very indirect change to the situation we were in before. 15:25:47 we said that EOL in mid-2019 (?) is our hard deadline. 15:25:52 mid-2020 15:25:54 not 2019 15:26:08 and we're already in a situation where we don't have backups for the machine. 15:26:35 yes. I think TorDNSEL should be a priority after scalability now. 15:26:40 but why? 15:26:50 I'm saying that not much has changed. 15:27:20 the priority considerations from two weeks ago are still valid. 15:27:21 because it seems that we are blocking other team on this and we may have a bigger problem with it later 15:27:26 karsten: yes 15:27:31 i also think that having it at the end of the roadmap is the right place for it, it started out at the beginning of the roadmap in stockholm and systematically everything else was a priority above it 15:27:35 we need to plan to include the TorDNSEL in the roadmap 15:27:42 it is in the roadmap 15:28:05 omg... i was looking at a filtered roadmap :| 15:28:13 (you can filter the roadmap?!) 15:28:19 i think i had it starting end of october/start nov on the stickies 15:28:24 (yes... it was focus on scalability) 15:28:55 we have #29653 in the backlog 15:29:24 * phw status: merging and deploying #9316 15:29:34 so, 5 seconds before gaba disappears. 15:29:41 what do we say on the tordnsel ticket? 15:29:53 "EOY seems realistic"? 15:29:54 when do we start working on it? how long it will take to complete? 15:30:29 likely not before Q4, depends on what version of our plans we're going to implement. 15:30:49 but I think that's more information than required here. 15:31:26 We could start in October and be done by end of December? 15:31:51 sounds plausible to me. 15:32:13 ok. Let's do that then. I'm moving the proposal for scaling to say that this is metrics can start jan 1st 2020 15:32:20 and we wrap all this before 15:32:23 ok 15:32:38 okay. 15:32:47 can one of you update ticket #29399? 15:32:50 (gaba: don't forget your thing, it's been 30 min) 15:32:51 with this info 15:32:58 yes... runnig 15:33:00 o/ 15:33:03 o/ 15:33:06 thanks!! 15:33:38 should I update the ticket? 15:33:49 yes, ok 15:34:13 alright, 15:34:34 let's talk about the next two weeks in the field. :) 15:35:08 sounds like reviews will be difficult during that time. 15:35:22 yes, that is likely 15:35:29 can we get the snowflake stuff deployed before you leave? 15:36:03 i am probably going to be unable to do much more than an hour after the meeting 15:36:08 ok. 15:36:13 then this won't work. 15:37:08 is the deployment of collector blocking something? 15:37:33 not really, it would just be about finishing this task. 15:37:41 but it's fine to do it in two weeks. 15:37:47 ok 15:38:15 #31204 would be something to maybe also do in collector and deploy at the same time? i don't think there's a lot of code overlap there 15:38:37 yes, true. 15:38:52 moved to In Progress. 15:39:23 what did you mention earlier about fast/guard flags? 15:39:48 basically it involves alternate consensus generation 15:40:20 is that something I could try to move forward in the coming two weeks? 15:41:00 i think it might be easier if you start at the other end of this pipeline, which is onionperf data analysis 15:41:01 and is it related to this roadmap item? Emulate different Fast/Guard cutoffs in historical consensuses (Aug 19) 15:41:12 yes, that's the roadmap item 15:41:19 what does the Aug 19 part mean there? 15:41:31 i had things in months in the roadmap 15:41:34 in stockholm on stickies 15:41:45 it's a 10 point sticky though 15:41:52 is this 2019-08-19? 15:42:38 i'm not sure why it's due then 15:42:39 or 2019-08-31? 15:42:55 i think this is something gaba has added based on where things were on the roadmap wall 15:43:02 ok. 15:43:09 anyway, by onionperf data analysis, 15:43:20 you mean this other roadmap item: 15:43:23 identifying poorly performing relays by correlating historical onionperf data 15:43:26 Use emulated consensus with historical OnionPerf data to predict Tor performance with modified consensus Fast/Guard cutoff values 15:43:34 sort of 15:43:49 ah, ok. 15:43:52 i've got plans for the modified alternate reality consensus, but so far not for doing the onionperf data analysis 15:44:35 well, the task I suggested was to simply exclude measurements containing relays that would be dropped from the consensus with different fast/guard parameters. 15:44:40 so we need better tools for identifying poorly performing relays, recalculating network aggregates if we exclude certain relays, and working out some metric of "did we exclude enough poorly performing relays without sacraficing good ones" 15:45:00 the task you suggested (I think) is to look at onionperf data and find correlations between slow relays and slow measurements. 15:45:25 the task is to look at onionperf data and see if it's possible to identify which relay it is that is badly performing 15:45:38 the data might be too sparse for this 15:45:44 maybe, yes. 15:45:51 but okay, worth taking a look. 15:45:59 in which case, yes, then the task is only recalculating based on excluding relays 15:46:19 we'd want to iterate this quickly, so the tools need to be fairly efficient for doing this 15:46:22 I'll run with this. 15:46:26 awesome (: 15:46:27 yeah. 15:46:43 we did talk about using a postgres db if it helps to speed things up 15:47:04 did you start anything there? 15:47:15 nope, i've only looked at the fast/guard cutoff stuff so far 15:47:16 I could probably build such a database. 15:47:23 ok cool 15:47:28 but I don't want to redo work you already thought a lot about. 15:47:41 all the stuff i've done so far is dir-spec, not onionperf 15:48:28 do you mind writing down two paragraphs about what you did? 15:48:41 just to be sure that I'm not doing it once again? 15:48:45 i will put these tickets in trac before i pack up 15:48:52 okay, great! 15:49:19 roadmap! 15:49:24 anything else we need to move around there? 15:49:41 next week we won't have a meeting, right? 15:49:55 or at least you and acute wouldn't be there. 15:50:02 i've been moving things as i go along, so everything there is correct on the roadmap 15:50:18 well, aren't you in a field? 15:50:24 i will leave in-progress things in progress though i'm not working on them, as they are in progress i just don't have any work time 15:50:26 are you going to work on roadmap stuff this week? 15:50:35 unless you think we should move them back 15:50:44 I don't know how this works in a sprint. 15:51:01 you could move them to the top of backlog, maybe? 15:51:17 if the goal is to clear In Progress at the end of the sprint/week? 15:51:18 how about we update each of the tickets with the progress up to the point we are pausing, then put them back on the backlog? 15:51:45 I think that would work. 15:51:58 i guess it is possible we would come back after 2 weeks to disasters and might need to reprioritise, and we don't want to lose state 15:52:06 right! 15:52:28 will move tickets 30763 and 30792 to on review, as I have a merge request planned for today 15:52:50 ah ok cool 15:53:17 okay, great! 15:53:30 I think that's all for the roadmap then. 15:53:39 any other topics for today? 15:53:46 a bit of news 15:53:52 yes? :) 15:54:01 I exported all onionperf tickets from trac and imported them into gitlab 15:54:19 exciting! 15:54:37 ah yes, i've been calling them onionperf#XXX instead of #XXX so we can differentiate 15:54:42 like on the roadmap 15:55:10 makes sense. 15:55:34 anything we need to do on the trac side? 15:55:40 it makes sense to keep them in both places 15:55:55 the import process does not work for all the comments on the ticket, just for the initial description 15:56:08 the trac component is archived, the tickets closed, but they are still referenced 15:56:19 okay. 15:56:44 any new OP issue should be opened in gitlab 15:56:45 i don't know if gaba would be interested in acute's export/import procedure 15:56:50 should ask when we are back 15:56:55 yep! 15:57:20 :) 15:57:21 let's see how this works. 15:57:37 looking forward to moving more components to gitlab, but waiting patiently. ;) 15:57:50 i've found some scary issues that need resolving first 15:58:01 like doing git push deletes all merge requests 15:58:14 (i know the fix though) 15:58:17 heh 15:58:26 good to give it some testing this way. 15:58:34 yeah 15:58:47 alright, we're running out of time for today. 15:58:56 enjoy camping! 15:59:09 thanks! 15:59:17 (: 15:59:18 and talk to you in 2 weeks! 15:59:22 yep 15:59:30 #endmeeting