[tor-bugs] #9321 [Tor]: Load balance right when we have higher guard rotation periods

[Tor Bug Tracker & Wiki]

#9321: Load balance right when we have higher guard rotation periods
-------------------------+-------------------------------------------------
     Reporter:  arma     |      Owner:
         Type:  project  |     Status:  new
     Priority:  normal   |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  needs-proposal, tor-auth, tor-
Actual Points:           |  client, 026-triaged-1
       Points:           |  Parent ID:  #11480
-------------------------+-------------------------------------------------

Comment (by nickm):

 Replying to [comment:22 asn]:
 [...]

 > Then 5 minutes before the hour, little-t-tor will read the guardiness
 output file and consider its data when voting.

 This all seems plausible; can any dirauth ops comment on whether this is a
 reasonable thing to set up?

 > Some notes:
 >
 > * Instead of downloading the latest consensus from metrics, maybe we
 could add little-t-tor code that would save new consensuses into a
 directory. This way, we don't need to download bulk from metrics, apart
 from during the bootstrap procedure.

 This seems plausible and not terribly hard.  The only thing to deal with
 here would be getting rid of old files.  (see below.)

 I guess you could have a "KeepOldConsensuses 90 days" option along with
 "OldConsensusDir /var/xyzzy" that would store the last 90 days of
 consensuses in some directory of your choice.

 > * To avoid keeping old summary/consensus files around that take over
 disk space, I added some optional cleanup switches to the scripts.
 Specifically, the `summizer.py` script can delete the consensus files that
 got summarized and can also delete consensus files older than 3 months (or
 N months). Similarly, the `guardiness.py` script can delete summary files
 older than 3 months (or N months). The idea is that every time the cron
 job triggers, the `summizer.py` and `guardiness.py` scripts will auto-
 delete the oldest summary/consensus file, keeping in disk only the useful
 files.

 This also seems plausible.  Except instead of deleting the oldest
 unconditionally, it's probably best for them to delete any consensus whose
 valid-until time is more than N days before the current time.  That way,
 if you have to re-run them, or if you mess up mtimes on your disk, they
 don't wind up deleting things they shouldn't.

 (Do you have more questions?  If so, please make sure they end with a ? or
 I am likely not to realize that they are questions. :) )

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