[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3773: Merge adding lease with renewing lease (was: Merge adding lease with renewing lease (for immutables))

[Tahoe-LAFS]

#3773: Merge adding lease with renewing lease
--------------------------+-----------------------------------
     Reporter:  itamarst  |      Owner:  itamarst
         Type:  task      |     Status:  new
     Priority:  normal    |  Milestone:  HTTP Storage Protocol
    Component:  unknown   |    Version:  n/a
   Resolution:            |   Keywords:
Launchpad Bug:            |
--------------------------+-----------------------------------
Description changed by itamarst:

Old description:

> 1. From a client perspective, the goal is just to have a lease, whether
> it's a new lease or renewing a lease is irrelevant; renewing is
> essentially an optimization detail on server side.
> 2. Cancelling leases is not actually supported.
> 3. The way lease renewal secrets are generated is likely to change in the
> switchover from foolscap to HTTP.
> 4. Internally, the server _already_ treats renewing a lease as
> potentially adding a new one if renewal fails.
>
> As such, the distinction between adding a lease and renewing a lease is
> unnecessary (presuming item 4 is actually correct!). We would like to
> simplify HTTP protocol by removing it, and we need to make sure server
> can gracefully handle clients switching their renewal secret.
>
> Therefore, we should merge the two into a single operation:
>
> 1. Validate item 4 above, since it's critical requirement for the rest of
> this.
> 2. In Foolscap client, switch to only using renewal code path.
> 3. Make sure server creating new lease when renewal fails is well tested,
> so users don't lose data.
> 4. On server-side, leave new lease Foolscap endpoint in place for
> backwards compat.
> 5. In new GBS HTTP protocol spec, switch to a single end point for lease
> creation/renewal, and remove all references to lease cancellation secret.

New description:

 1. From a client perspective, the goal is just to have a lease, whether
 it's a new lease or renewing a lease is irrelevant; renewing is
 essentially an optimization detail on server side.
 2. Cancelling leases is not actually supported.
 3. The way lease renewal secrets are generated is likely to change in the
 switchover from foolscap to HTTP.
 4. Internally, the server _already_ treats renewing a lease as potentially
 adding a new one if renewal fails.

 As such, the distinction between adding a lease and renewing a lease is
 unnecessary (presuming item 4 is actually correct!). We would like to
 simplify HTTP protocol by removing it, and we need to make sure server can
 gracefully handle clients switching their renewal secret.

 Therefore, we should merge the two into a single operation:

 1. Validate item 4 above, since it's critical requirement for the rest of
 this.
 2. In Foolscap client, switch to only using renewal code path.
 3. Make sure server creating new lease when renewal fails is well tested,
 so users don't lose data.
 4. On server-side, leave new lease Foolscap endpoint in place for
 backwards compat.
 5. In new GBS HTTP protocol spec, switch to a single end point for lease
 creation/renewal, and remove all references to lease cancellation secret.
 6. Clients should continue to try to pass in the same renewal secret, the
 way they do now.

--

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