16:58:53 #startmeeting 16:58:53 Meeting started Wed Jun 11 16:58:53 2014 UTC. The chair is meejah. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:58:53 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:05 so for agenda, i have: 16:59:08 1. updates 16:59:28 2. more-open merging for "next", or another branch? 16:59:35 anything else? 17:00:02 anything we need to discuss regarding deployment? (I have no news though.) 17:00:20 3. deployment stuff? 17:00:34 nothing else from me. 17:00:37 okay. lets start with 1. 17:00:40 #topic 1. updates 17:01:10 i'll start. i merged two of lucyd's branche (search, onionoo_wrapper) and pushed to a branch in my repo 17:01:22 and sent a couple emails about deployment 17:01:41 #action meejah needs to merge pull-req from jondbaker from yesterday 17:01:42 #info added couple of small checks like 'is_stable' and 'is_hibernating' to onionoo-wrapper utilities 17:01:43 did you merge anything into next which I should pull-and-push? 17:01:51 karsten: no 17:01:54 ok 17:02:19 oops karsten go ahead 17:02:27 #info merged lucyd's search, onionoo_wrapper 17:02:28 ah no 17:02:33 #info mailed about deployment 17:02:36 lucyd: didn't want to interrupt. 17:02:44 okay, lucyd go ahead 17:03:43 ok after making minor modifications to the wrapper, I rewrote the tshirt script(#9889) 17:04:19 #info also changed the relay-search script(#11956) 17:05:00 lucyd: tshirt thing, is there a pull-request or merge I haven't done for that? 17:05:32 well, the ticket is not a part of the weather-rewrite so I didn't update it anywhere 17:05:55 i dont think there is a ticket for the rewrite specifically 17:06:04 should we add one now in the wiki? 17:06:23 #action lucyd add a ticket for tshirt to wiki 17:06:37 #info i think some front-end tweaking is all it takes to make this relay-search script integrated with the new weather 17:06:46 great! 17:07:10 does it have tests? (unit or an integration?) 17:07:17 nickm: i am revising bridgedb's concept of "what a bridge is" and "what a hashring is", and we're currently using the `ring = set([elements]); key = sha1(client); pos = key % len(ring)` method… do you think using consistent hashing would work better? http://www.tomkleinpeter.com/2008/03/17/programmers-toolbox-part-3-consistent-hashing/ 17:07:34 well not yet...i'm working on updating(and testing) the wrapper first 17:07:41 okay 17:07:58 do you feel you're on schedule, overall progress-wise? 17:08:00 anyways, the interaction between the relay-search script and the wrapper wouldn't change though 17:08:40 meejah : yeah, it looks ok but I'll be chipping in more hours so we have ample time to test and debug later 17:09:04 okay 17:09:15 any more updates? or can we move to 2? 17:09:19 btw, meejah karsten : have you looked at the wrapper? 17:09:36 i have 17:09:37 after meejah's reply yesterday i'm working on updating the caching module 17:09:46 lucyd: unfortunately not. :( 17:10:10 i would say just rip it out for now, and once the system is working add back in? 17:10:11 glad that meejah has. 17:10:29 meejah : okie dokie 17:10:51 i.e. i'd rather see a working (with tests) version first, then add (back) the caching. and/or use luketheduke's 17:11:29 (using memcached seems like the right choice here, since you've got web stuff and cron-run scripts etc) 17:11:39 ...but let's worry about that feature later :) 17:11:41 oh hi. 17:11:51 was there a meeting scheduled for today? 17:11:52 #topic 2. next branch 17:12:21 luketheduke: yes, i didn't get out a timely reminder this week...but it's same-time-same-place each week 17:12:30 the wiki page still says next meeting is in may >_> 17:12:45 luketheduke: want to update it? :) 17:12:49 ooo, that's a fail for me from last-time's #action to update wiki page :/ 17:12:57 anyway I'm here (: 17:13:08 karsten: I don't think I have all the info needed to update it 17:13:08 * meejah was away 5 days this week... 17:13:34 i'd like somewhere we can merge changes that won't get auto-sucked into production 17:13:34 luketheduke: ok. sounds like meejah was planning to do it? otherwise I can do it. 17:13:52 #action karsten update wiki page w/ meeting schedule 17:13:54 :) 17:14:03 meejah: into a branch called "development"? >_> 17:14:14 i.e. either karsten agrees not to merge anything from "next" or ... ^^ what luketheduke said 17:14:50 okay, i'll make a branch called "devel" and more-rapidly pull things into there 17:15:08 ...and merge "ready to go into production" things to next (as per current plan) 17:15:15 ok 17:15:15 sound good? 17:15:23 (wiki page updated.) 17:15:26 #agreed create and use "devel" branch in tor-weather 17:15:43 oops, didn't mean to hit return just yet on that ;) 17:16:06 okay, if nobody has more on that, let's move to 3 17:16:18 #topic 3. deployment updates? 17:16:25 so, we still have no reply from our sysadmins. 17:16:36 #info no real update, karsten and i emailed, and waiting for sysadmin reply 17:16:43 how bad would it be to develop with just-wheezy-packages in mind for now? 17:16:52 wheezy+wheezy-backports 17:17:01 it makes "using OnionPy" harder 17:17:04 no objections, as long as -backports stays in 17:17:23 -backports should stay in, yes. 17:17:37 ...but we're already defering that to later anyway at this point 17:17:41 ok 17:17:48 (python-requests in wheezy is an unusably old version) 17:18:13 #info we do at least need wheezy-backports i'd say 17:18:26 I'm optimistic about that. 17:18:32 #info at least for python-requests 17:18:42 also, will ping sysadmins later today. 17:19:22 #action meejah to read more about recommended django deployment 17:19:44 #info currently, it's behind apache (right, karsten?) 17:19:58 yes, and I think we'll want to keep it behind apache in the future. 17:20:23 btw, I was wondering if we could turn this "research how to deploy something on a tor machine" into something more general than just weather. 17:20:27 #info will be deployed behind apache 17:20:39 I bet other tor devs frequently wonder about these questions, too. 17:20:50 yes, i can write something like "how to deploy a python-thing to a tor-machine"? 17:20:58 is there a rationale behind using apache| 17:21:01 ? 17:21:18 meejah: I think that would be quite useful. using sysadmin input. 17:21:19 * meejah defers to karsten 17:21:29 luketheduke: our sysadmins know apache pretty well. 17:21:35 #action meejah to write up deployment findings as HOWTO 17:21:41 ok 17:22:03 * meejah agrees defering to sysadmin's choice of webserver makes sense 17:22:09 Does anyone have time for a quick tor question? 17:22:23 HB33: -> #tor 17:22:26 i think that closes the meeting, unless there any more topics? 17:22:37 #action meejah needs to merge jondbaker pull-req with more tests 17:22:39 meejah: on a side note, developing the backend scripts requires using the cache feature 17:22:51 lucyd: why? 17:23:28 meejah: for example, the hourly script has to keep downloading onionoo docs 17:23:40 and the protocol insists usage of 'If-Modified-Since' header 17:23:41 how many docs? 17:23:56 well, you can of course send requests without that header. 17:24:08 if you don't have any older documents available. 17:24:21 karsten : ok and then update them once the feature is implemented? 17:24:27 since OnionOO updates hourly, an hourly script doesn't really need to use caching. 17:24:41 don't worry too much about overloading onionoo. it has moved to a new server which should handle the load. 17:24:55 lucyd: for now, we use live onionoo req's for everything. 17:24:58 luketheduke: consider the daily script as well 17:25:02 lucyd: just let me know when you think you broke it. ;) 17:25:06 lucyd: that even less. 17:25:06 if weather is pounding it, we do caching sooner ;) 17:25:16 it's a very good idea to have caching in place when you go into production, but for testing, meh, who cares. 17:25:33 luketheduke: yes :) 17:25:49 alright then 17:25:50 lucyd: maybe restrict your test set to just a few relays, so that your tests don't run forever. 17:26:05 but otherwise, just do the requests you need. 17:26:12 i believe the vagrant setup includes some test-data? 17:26:51 * karsten doesn't know that. 17:27:09 lucyd: for testing (e.g. unit-tests) you'd likely want to mock out the onionoo wrapper and feed it the test data (i.e. no onionoo req at all) 17:27:58 ah, yes, no onionoo requests in unit tests, please. 17:28:31 #endmeeting