[tahoe-lafs-trac-stream] [tahoe-lafs] #1382: immutable peer selection refactoring and enhancements

tahoe-lafs trac at tahoe-lafs.org
Sat Nov 16 04:45:01 UTC 2013


#1382: immutable peer selection refactoring and enhancements
-------------------------+-------------------------------------------------
     Reporter:  kevan    |      Owner:  markberger
         Type:           |     Status:  new
  enhancement            |  Milestone:  1.11.0
     Priority:  major    |    Version:  1.8.2
    Component:  code-    |   Keywords:  review-needed servers-of-happiness
  peerselection          |  blocks-release
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by zooko):

 Here is another review of [https://github.com/markberger/tahoe-
 lafs/blob/fa6f3cfb1e258e4427f35a7aada05c7ad2c9dd13/src/allmydata/immutable/upload.py
 upload.py from the current tip of 1382-rewrite-2]. I'm looking at
 [https://github.com/markberger/tahoe-
 lafs/blob/fa6f3cfb1e258e4427f35a7aada05c7ad2c9dd13/src/allmydata/immutable/upload.py#L466
 _get_next_allocation() on line 466], and it seems like it is doing some
 complicated computations in order to yield just a simple data structure —
 the ordered list of [(server, set(shnums))] that constitute the upload
 plan. It seems like the "calculate upload plan" (a.k.a.
 {{{_calculate_tasks()}}} method could just generate that list and return
 it and {{{_get_next_allocation()}}} could disappear. Am I missing
 anything?

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382#comment:58>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage


More information about the tahoe-lafs-trac-stream mailing list