[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3767: Potential issues with `POST /v1/lease/<share-index>`

Tahoe-LAFS trac at tahoe-lafs.org
Thu Aug 19 19:29:24 UTC 2021


#3767: Potential issues with `POST /v1/lease/<share-index>`
--------------------------+-----------------------------------
     Reporter:  itamarst  |      Owner:  exarkun
         Type:  task      |     Status:  new
     Priority:  normal    |  Milestone:  HTTP Storage Protocol
    Component:  unknown   |    Version:  n/a
   Resolution:            |   Keywords:
Launchpad Bug:            |
--------------------------+-----------------------------------

Comment (by exarkun):

 I don't really understand why lease renewal on mutables has this nodeid
 thing.  Or... I don't understand why mutables and immutables differ in
 this.
 If you try to renew a lease on an immutable with a renewal secret that
 matches no lease on the bucket then it raises an IndexError at you telling
 you your secret is unknown.
 If you try to renew a lease on a *mutable* with a renewal secret that
 matches no lease on the bucket then it raises an IndexError at you telling
 you your secret is unknown *and* giving you the nodeid on which all leases
 it does know about were created.
 I suppose I see the point of the latter behavior (though I always
 misunderstood it until just now).  If storage1 is decommissioned in some
 orderly fashion and all of its storage is taken over by storage2 then when
 the client shows up to renew leases for shares originally uploaded to
 storage1 it will compute a different renewal
 secret because it will use storage2's id as part of the hash input.
 So the renew is going to fail because the different renewal secret no
 longer matches the lease the client expects to be renewing.
 Fine.  I suppose that putting the information into the text content of an
 IndexError means that nothing ever _actually_ uses it and ... something
 else happens, I dunno what.  But whatever.
 So why does that logic apply only to mutables, not immutables?
 Is it just the unsurprising consequence of having two nearly identical
 codepaths implementing what should really be the same thing?  They
 eventually unintentionally diverged?
 "eventually" being 68d3d620026330bc14fc27218f1c81023188c657 in 2007...

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


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