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

[tahoe-lafs]

#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):

 transcribed from IRC:

 So, now I'm still confused about https://github.com/markberger/tahoe-
 lafs/blob/6f5a125283494d3bbf1d2fa143eddd3d5183c7d7/src/allmydata/test/test_upload.py#L734
 is_happy_enough()
 It uses k.
 Why does it do that?
 The (modern) definition of happiness doesn't include mention of K, right?
 (It's just that nobody ever sets their H requirement to less than their
 K.)
 So I suspect that is_happy_enough() isn't calculating exactly th right
 function, but we don't notice because it gets called only for well-
 distributed things, by test_upload, so "return True" also works for the
 current tests. (I tried this, and {{{return True}}} does indeed give the
 correct answer for all queries that test_upload.py sends to the
 {{{is_happy_enough}}} function.)
 But it seems like we ought to replace it with a function that calculates
 the correct thing, to avoid confusing future test-writers.

 So Mark: please write a new {{{is_happy_enough}}}, or explain to me why
 I'm wrong, or replace the call to {{{is_happy_enough}}} with a call to
 {{{allmydata.util.happinessutil.servers_of_happiness}}}.

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