[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