[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1363: refactor storage_client.py, use IServer objects instead of rrefs

[Tahoe-LAFS]

#1363: refactor storage_client.py, use IServer objects instead of rrefs
------------------------+---------------------------
     Reporter:  warner  |      Owner:  warner
         Type:  task    |     Status:  closed
     Priority:  major   |  Milestone:  1.9.0
    Component:  code    |    Version:  1.8.2
   Resolution:  fixed   |   Keywords:  review-needed
Launchpad Bug:          |
------------------------+---------------------------

Comment (by Brian Warner <warner@…>):

 In [changeset:"54f974d44c3d740bf1a41624d5a001952561c3d2/trunk"
 54f974d/trunk]:
 {{{
 #!CommitTicketReference repository="trunk"
 revision="54f974d44c3d740bf1a41624d5a001952561c3d2"
 make IServer.get_serverid() use pubkey, not tubid

 This is a change I've wanted to make for many years, because when we get
 to HTTP-based servers, we won't have tubids for them. What held me back
 was that there's code all over the place that uses the serverid for
 various purposes, so I wasn't sure it was safe. I did a big push a few
 years ago to use IServer instances instead of serverids in most
 places (in #1363), and to split out the values that actually depend upon
 tubid into separate accessors (like get_lease_seed and
 get_foolscap_write_enabler_seed), which I think took care of all the
 important uses.

 There are a number of places that use get_serverid() as dictionary key
 to track shares (Checker results, mutable servermap). I believe these
 are happy to use pubkeys instead of tubids: the only thing they do with
 get_serverid() is to compare it to other values obtained from
 get_serverid(). A few places in the WUI used serverid to compute display
 values: these were fixed.

 The main trouble was the Helper: it returns a HelperUploadResults (a
 Copyable) with a share->server mapping that's keyed by whatever the
 Helper's get_serverid() returns. If the uploader and the helper are on
 different sides of this change, the Helper could return values that the
 uploader won't recognize. This is cosmetic: that mapping is only used to
 display the upload results on the "Recent and Active Operations" page.
 I've added code to StorageFarmBroker.get_stub_server() to fall back to
 tubids when looking up a server, so this should still work correctly
 when the uploader is new and the Helper is old. If the Helper is new and
 the uploader is old, the upload results will show unusual server ids.

 refs ticket:1363
 }}}

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1363#comment:40>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage