14:00:01 #startmeeting metrics team 14:00:01 Meeting started Thu Oct 6 14:00:01 2016 UTC. The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:01 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:07 shall we start? 14:00:14 looks like we already have a few agenda items. 14:00:14 ok. 14:00:20 or do you need more time? 14:00:26 al fine. 14:00:29 all. 14:00:32 ok. 14:00:37 * CollecTor sync (iwakeh) 14:01:16 currently I'm polishing the code and implementing tests, one 14:01:28 question for the merging: 14:01:44 with #20228 14:02:08 we decided to store by acquisition time 14:02:16 yep. 14:02:32 So, which is the acquisition time for descs from other instances? 14:02:49 The sync-time. 14:03:06 Does this still make sense for 14:03:10 torperf? 14:03:37 * karsten looks at code 14:04:21 rsyncCatString in ArchiveWriter is relevant here, I think. 14:04:28 we're setting that string once per execution. 14:04:41 and using it for server descriptors and extra-info descriptors. 14:04:46 we could use it for all other descriptors, too. 14:05:06 so, the specifics of torperf are a fine question though. 14:05:16 That's not the question. I think. 14:05:35 okay, just torperf is the question? 14:05:37 CollecTor one downloads torperf-1 14:05:59 CollecTor two syncs torperf-1 from C1. 14:06:07 can we ignore torperf? 14:06:18 should c2 store torperf using the date 14:06:22 hu? 14:06:22 in the sync, I mean. 14:06:35 oh, you mean leave it out? 14:06:38 yep. 14:06:49 well, that reduces the effort. 14:06:50 the most important descriptors for sync are relaydesc. 14:06:57 bridgedesc are useful, too. 14:07:00 exitlist maybe, too. 14:07:02 micro? 14:07:02 but torperf, meh. 14:07:08 micro are part of relaydesc. 14:07:13 yes. 14:07:21 exit-lists 14:07:31 yes, somewhat useful. 14:07:38 we should include those. 14:07:48 unless it's hard. 14:07:51 fine, then no sync for torperf. 14:07:56 sounds good. 14:08:04 we should think about sync for onionperf though. 14:08:07 when we get to that. 14:08:26 well, the files will be different ? 14:08:29 sure, sure. 14:08:40 the architecture is open for all that. 14:08:46 ok. 14:08:48 the new one. 14:08:52 heh yes. 14:08:53 ;-) 14:09:24 that's it. 14:09:29 what's the time frame here? 14:09:35 when should I reserve time to review patches? 14:09:39 ops 14:09:43 I'm here as well! 14:09:44 unless there are unexpected thing 14:09:48 hello anathema_db. 14:09:48 (sorry I missed the start) 14:09:50 hi! 14:10:01 sorry for being absent 14:10:05 continuing: 14:10:22 next week. 14:10:29 great! 14:10:51 alright. moving on? 14:10:55 sure. 14:10:59 * October tasks on the roadmap (karsten) 14:11:21 2016-10: Provide user-friendly documentation that empowers users to independently operate CollecTor instances. (Sponsor X 1.2. CollecTor) 14:11:24 2016-10: Enable CollecTor to synchronize Tor network data from other CollecTor instances. (Sponsor X 1.3. CollecTor) 14:11:27 2016-10: Set up a second CollecTor instance and enable synchronization with the first CollecTor instance. (Sponsor X 1.4. CollecTor) 14:11:42 1.3 and 1.4 are yours right now. 14:11:44 the last two are in progress. 14:11:47 right. 14:11:53 I started looking into 1.2 yesterday. 14:12:04 fine. 14:12:10 which is the next topic on the agenda. 14:12:17 so, I guess we have october under control for now. 14:12:23 definitly. 14:12:30 great! 14:12:37 * Operating manuals (karsten) 14:12:45 actually, just one. 14:12:51 yes? 14:13:20 unless you split for different 14:13:28 ah, you mean just one manual? 14:13:39 tasks like sync, and regular operation. 14:13:43 yes. 14:13:51 nah, one manual for collector is enough. 14:14:05 huge volume :-) 14:14:09 what I did was go one step back and look at how we're operating services more generally. 14:14:23 which includes metrics, onionoo, and exonerator, too. 14:14:29 painful experience. 14:14:37 anyway, I started a latex document here: 14:14:41 collector is easier. 14:14:58 https://storm.torproject.org/shared/A5qfhTJQmArPRewCZAhpqpqsYSUKJ9K3AYc9czrtroy 14:14:59 will be ... 14:15:09 collector was comparatively easy, metrics is harder. 14:15:41 I can send you a link that can edit, I just didn't want everyone here to help editing. ;) 14:15:42 * iwakeh waiting for the doc .. 14:16:03 true :-) 14:16:12 basically, I asked myself what questions future operators might have. 14:16:23 it takes long for the LaTeX 14:16:34 I can also upload a pdf somewhere. 14:16:43 now it's there. 14:16:46 ok! 14:17:15 * iwakeh reading ... 14:17:16 so, the idea was to use this format as a working format, to compare operating the four services. 14:17:28 and then produce or update manuals based on this doc. 14:17:34 okay, waiting.. 14:18:25 I think it goes too far for CollecTor ... 14:18:32 for example, 14:18:47 we provide a signed verified download 14:19:03 no need for ant and all the java packages for operation. 14:19:09 I thought about that. 14:19:20 no need to specify a unix user 14:19:23 the issue is that the release is outdated. 14:19:29 ? 14:19:40 the current? 14:19:40 for bridgedescs we need latest git. 14:19:49 we should release more often. :) 14:19:52 well, release 14:19:55 right 14:19:56 :-) 14:20:03 and then simplify the instructions. 14:20:06 no git for operation. 14:20:07 but I see your point. 14:20:15 yeah, that would be neat. 14:20:22 not there yet. 14:20:28 no ant and just plain jvm. 14:20:31 I tried to capture the current state. 14:20:51 collector is there. 14:21:02 unless, you hide releases ;-) 14:21:09 should I release? 14:21:16 yes. 14:21:24 it's merged and running. 14:21:37 projects release worse things ... 14:21:38 ah, I thought we were waiting for sync. 14:21:41 hehehe 14:21:52 okay, cool! 14:21:53 minor version releases can 14:21:56 fit in. 14:22:14 operation would only need to replace 14:22:22 the jar. 14:22:28 yep! 14:22:34 so all fine. 14:22:42 okay, will release tomorrow. 14:22:46 1.1.0, right? 14:22:55 1.0.1 14:23:04 # Changes in version 1.0.1 - 2016-08-22 14:23:09 we already have an 1.0.1. 14:23:15 1.0.2 14:23:22 okay. 14:23:27 # Changes in version 1.1.0 - 2016-09-xx 14:23:31 -> 1.0.2 14:23:38 -> 1.0.2 - 2016-10-07 14:24:11 alright, and then I can simplify instructions. 14:24:24 that should be simplified. 14:24:35 basically, we 14:24:54 should stay away from all operating system related. 14:25:01 after all it's a java 14:25:13 application; platform independent. 14:25:25 (well ...) 14:25:27 uhhh.. 14:25:34 not there yet, I think. 14:25:46 well, do you mean windows? :) 14:25:47 apache is not part of 14:25:52 the manual. 14:26:05 I do not want to support m$ systems 14:26:12 phew. 14:26:22 but, the operating manual should abstract 14:26:26 from the OS. 14:26:38 as far as possible. 14:26:42 as far as possible. 14:26:52 there is only room to actually support debian. 14:27:05 but, the abstraction helps reducing 14:27:15 it such manuals to the minimum. 14:27:17 regarding apache, I think we need to include that in the manual. 14:27:31 we're somewhat apache-specific with .htaccess and header.html etc. 14:27:36 Or, demand that operators know how to run that. 14:28:02 there are only docs served 14:28:13 no matter which http-server is used. 14:28:17 that's a tough question: what can we demand operators to know vs. how many potentially great operators will be shy away? 14:28:22 the apache related stuff could 14:28:28 classify as example. 14:28:44 i'd say look 14:29:01 at the operators for my mirror and the main collector. 14:29:21 what they know is minimum for such a service. 14:29:41 not minimum, but in that .. 14:29:46 direction. 14:30:02 otherwise the http server will be easy pray. 14:30:35 oh, I agree that folks should know how to set up apache.. 14:30:46 ups, prey 14:30:54 what we need to tell them, though, is what specifically we need from their apache setup. 14:30:59 which files to serve. 14:31:10 yes. 14:31:18 which would ideally be in a single directory. but, not there yet. 14:31:18 but not how. 14:31:29 true, but the current doc doesn't do that. 14:31:35 except suggest the package. 14:31:59 I think that most operators would use that list to get an overview what we're going to do to their system. 14:32:03 fine, I didn't complete reading yet. 14:32:10 you want me to install an openjdk-7-jdk, good bye! 14:32:18 things like that. 14:32:19 or oracle 14:32:35 oracle java that is. 14:32:54 okay, I'll continue with metrics and then onionoo and exonerator. 14:32:59 it's still a work in progress as you can see. 14:33:02 for the task 14:33:15 1.2 for sponsorX 14:33:29 we need a doc just about collector. 14:33:37 but, this 14:33:43 yes, but we need a very similar doc 1 month later. 14:33:49 can be derived from the overview. 14:33:54 true. 14:34:04 have a LateX template. 14:34:24 oh, I just picked latex because of the table support. 14:34:31 we can easily use .txt or .md here. 14:34:35 rather txt for 14:34:37 for the actual manual. 14:34:41 yes 14:34:53 the overview is good. 14:35:06 especially for us to device a 14:35:09 I'll send you a link that can edit. 14:35:17 generc setup as far as possible. 14:35:19 fine. 14:35:31 yes, I think the questions will be the same for all services. 14:35:52 yes. 14:36:34 okay, moving on? 14:36:39 ok. 14:36:44 * Shutting down globe.torproject.org (karsten) 14:36:56 our sysadmins want to shut down globe.torproject.org. 14:37:06 yes? 14:37:10 right now it's serving javascript that redirects to atlas. 14:37:20 what implications? 14:37:27 which is in place for some months. 14:37:38 implications of shutting it down? no redirects anymore. 14:37:47 and one system less to take care of. 14:37:53 well, system or part of a system. 14:38:03 ok 14:38:17 I'm inclined to say yes. any objections or concerns I didn't see? 14:38:20 sad users? 14:38:26 uh, 14:38:38 what page will be served after shutdown? 14:38:47 error? 14:39:10 server not found I think. 14:39:17 http://glboe.torproject.org/ 14:39:22 like that. 14:39:51 maybe this is a more general question: how long do we keep redirects in place? 14:40:11 well, the redirect should indicate 14:40:14 another example: https://metrics.torproject.org/users.html 14:40:20 that's in place for years now. 14:40:30 which adds a tiny bit of complexity. 14:41:00 rather have less silent redirects in future. 14:41:08 telling people 14:41:17 they should change their bookmarks. 14:41:40 as static html page or specific status code or what? 14:41:46 even with an expiry date. 14:41:55 we could still do that with globe.torproject.org, I think. 14:41:59 for a few weeks. 14:42:00 static page with a link to the new. 14:42:13 people have to notice in order to learn. 14:42:17 :-) 14:42:32 actually a usability question. 14:42:59 okay, should we rewrite the globe redirect to make it more manual? 14:43:13 and more informing? :) 14:43:19 are there access numbers? 14:43:30 let me check.. 14:44:44 72 requests on oct 3. 14:44:59 well, new static page would be good. 14:45:17 the way it is now doesn't tell users that 14:45:23 it is expired. 14:45:35 would you want to rewrite what we have? 14:45:43 warning: javascript. 14:45:46 what is there? 14:46:04 where is it in source control......... 14:46:11 yes, I can do that. 14:46:35 wget https://globe.torproject.org/ 14:46:39 it'll be plain ugly, so people notice ;-) 14:46:43 not exactly source control, but heh. 14:47:03 heh 14:47:29 I think it's fine to keep that text and just suggest the link that users need to click themselves. 14:47:38 maybe add an expiration date. 14:47:41 oct 31. 14:47:45 which? 14:47:48 fine. 14:48:01 okay, let me first check with the admins that they're fine keeping it for another four weeks. 14:48:09 will get back to you as soon as I know. 14:48:16 ok. 14:49:01 how about I do the same with the metrics redirects? 14:49:20 yes, good idea. 14:49:37 https://collector.torproject.org/formats.html 14:49:43 there we have a manual redirect. 14:50:01 * iwakeh waiting 14:50:07 this looks fine. 14:50:42 okay! 14:50:46 out of topics. 14:50:52 maybe, a hint about bookmarks. 14:50:53 anathema_db: anything you'd like to add or ask? 14:51:07 iwakeh: oh, sure, feel free to make the text even better. 14:51:12 no folks, I was just reading and catching up 14:51:20 hope to be on track soon 14:51:21 I can then adapt the collector page. or you can fix that. 14:51:44 for release 1.0.2 14:51:55 you could add an 14:52:04 expiration date there too. 14:52:10 anathema_db: by the way, we recently wrote down some better hints for new contributors to metrics code bases. 14:52:24 oh cool 14:52:29 * karsten finds them.. 14:52:41 :D 14:52:52 unless, iwakeh, do you have a link faster than I? 14:53:22 https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/Volunteers 14:54:13 great thanks 14:54:22 anathema_db: if anything there doesn't make sense, or you have different questions, please let us know. 14:54:32 and also the faq: 14:54:33 https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/Documentation 14:55:05 karsten: sure 14:55:06 iwakeh: would you want to send an updated collector redirect page that I put into the 1.0.2 release? 14:55:09 there is a ticket number for questions and suggestions. 14:55:18 can do. 14:55:22 great! 14:55:59 okay. anything else? 14:56:10 no, all fine. 14:56:25 okay, cool! 14:56:48 thanks for a great meeting! talk to you next week, or earlier on trac. 14:56:53 bye! 14:56:59 bye, bye. 14:57:01 #endmeeting