[tor-bugs] #2755 [BridgeDB]: Reconsider BridgeDB's pool assignment file implementation and deployment

[Tor Bug Tracker & Wiki]

#2755: Reconsider BridgeDB's pool assignment file implementation and deployment
----------------------+-----------------------------------------------------
 Reporter:  karsten   |          Owner:     
     Type:  task      |         Status:  new
 Priority:  minor     |      Milestone:     
Component:  BridgeDB  |        Version:     
 Keywords:            |         Parent:     
   Points:            |   Actualpoints:     
----------------------+-----------------------------------------------------
 While deploying the new BridgeDB feature that dumps bridge pool
 assignments to disk, I had two ideas for improving that feature.  Neither
 of these ideas are critical, and I wanted to see how well the current
 implementation works before making it even more perfect.  Maybe we should
 revisit these ideas in a month or two from now.

  - We only write to assignments.log after parsing a new network status
 file, but not after dumping unallocated bridges to file buckets.  That
 means we might miss the fact that, say, Twitter distributes new bridges
 for up to 30 minutes between dumping to file buckets and reading the next
 network status.  Does that matter?  Should we also write to
 assignments.log after dumping to file buckets?

  - Appending to a single assignments.log file and rsyncing that to the
 host that sanitizes it won't scale forever.  We could run a monthly or
 weekly cronjob that runs `"mv assignments.log assignments.log.old"`.
 metrics-db can handle multiple input files and will read both files, as
 long as they are rsync'ed correctly.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2755>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online