[tahoe-lafs-trac-stream] [tahoe-lafs] #1116: clarify difference between full and read-only servers in servers-of-happiness failure message (was: make the servers-of-happiness error message less confusing)

tahoe-lafs trac at tahoe-lafs.org
Sun Sep 1 14:10:09 UTC 2013


#1116: clarify difference between full and read-only servers in servers-of-
happiness failure message
-------------------------+-------------------------------------------------
     Reporter:  kevan    |      Owner:  daira
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  1.11.0
    Component:  code-    |    Version:  1.7.0
  peerselection          |   Keywords:  easy unfinished-business usability
   Resolution:           |  error servers-of-happiness upload
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by zooko):

 * owner:  kevan => daira


Comment:

 I just read through the mailing list thread and the relevant source code.

 I believe the original issue report was mistaken, but there is still
 something confusing in this error message that should be clarified.

 The original report from Kyle Markley on the mailing list turned out to
 have a different error behind it — #1118. Kevan opened this ticket in the
 belief that Kyle was confused about the difference between a server being
 "full" and being "not quite full, but too full to accept that share
 there", but Kyle was not confused about that.

 I read through
 [source:trunk/src/allmydata/immutable/upload.py?annotate=blame&rev=196bd583b6c4959c60d3f73cdcefc9edda6a38ae
 the source] just now, and servers get counted as "full" by the uploader if
 either:

 a) They are read-only, the uploader queries them to see if they have a
 share, and they respond with something other than a failure, or

 b) They are not read-only, the uploader asks them to store one or more
 shares, and they store zero shares.

 I'm pretty sure that the current server will do b) only in the case that
 it is full.

 So I think the error message is already pretty accurate, except that it is
 combining full servers and read-only servers into one number. To close
 this ticket, track full servers (currently tracked in a member variable
 named {{{full_count}}} in the code separately from read-only servers, and
 change the error message from "of which %d placed none due to the server
 being full" to something like "of which %d placed none due to the server
 being full and %d found none already present on a read-only server".

 I don't think this ticket belongs in Milestone 1.11! Daira: could we move
 this to "soon"?

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


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