[tahoe-dev] [tahoe-lafs] #778: "shares of happiness" is the wrong measure; "servers of happiness" is better

[tahoe-lafs]

#778: "shares of happiness" is the wrong measure; "servers of happiness" is
better
--------------------------------+-------------------------------------------
 Reporter:  zooko               |           Owner:  kevan
     Type:  defect              |          Status:  new  
 Priority:  critical            |       Milestone:  1.5.1
Component:  code-peerselection  |         Version:  1.4.1
 Keywords:  reliability         |   Launchpad_bug:       
--------------------------------+-------------------------------------------

Comment(by kevan):

 I'm updating tests.txt to fix some bugs where I was mixing callbacks with
 synchronous code where I shouldn't have been. I also tweaked the share
 distribution for the comment:53 test so that the Tahoe2PeerSelector sees
 the servers in the right order.

 The simplest fix I can think of for the comment:53 issue changes the way
 that the [source:src/allmydata/immutable/upload.py at 4045#L313
 _got_response] method in a Tahoe2PeerSelector instance handles existing
 shares in a response.

 Right now, if a peer tells Tahoe2PeerSelector that it has a share that it
 wasn't asked to allocate (in the {{{alreadygot}}} part of the response),
 then the logic in _got_response will alter the entry for that share in
 {{{preexisting_shares}}} to point to the peer, regardless of whether or
 not that entry was already pointing to something else.

 It's kind of rough, but this check fixes the issue for me (in that it
 makes the test pass). Thoughts?

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/778#comment:63>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid