[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3901: End-to-end support for new HTTP storage protocol: tracking issue

[Tahoe-LAFS]

#3901: End-to-end support for new HTTP storage protocol: tracking issue
--------------------------+-----------------------------------
     Reporter:  itamarst  |      Owner:
         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:

> Each of these will be zero or more additional tickets:
>
> 1. #3902: Storage nodes can be started with HTTP protocol (It is maybe
> possible but not worth doing to do this via storage plugin.)
> 2. #3912: Storage nodes send the NURL to an introducer, in addition to
> the fURL for legacy Foolscap protocol. This is sent as an announcement
> upgrade so it supercedes existing announcement.
> 3. #3783: The introducer sends NURLs to storage clients. INVARIANT: old
> storage clients can safely get and ignore NURLs. If this is not the case,
> some conditional logic needs to be introduced so old clients don't get
> NURLs. It seems like this will just happen automatically, and moreover
> the announcement is just a dictionary with random keys, so hopefully will
> Just Work once #3912 is done.
> 4. DONE. The storage client understands NURLs, and use HTTP protocol
> instead of Foolscap when possible. See design doc for further discussion
> (QUESTION: is it actually possible to say "this furl and nurl are for the
> same server"? technically, maybe but not necessary given announcement
> upgrades).
> 5. Currently the storage client caches per-server FURLs indefinitely. New
> clients should check with introducer if a NURL (HTTP) has replaced a FURL
> (Foolscap) and update appropriately.
> 6. The client may only have FURL, and not have introducer. For that
> situation the Foolscap protocol should grow a away for clients to get new
> URLs (`remote_get_version`?)
> 7. Update the documentation appropriately.

New description:

 Each of these will be zero or more additional tickets:

 1. #3902: Storage nodes can be started with HTTP protocol (It is maybe
 possible but not worth doing to do this via storage plugin.)
 2. #3912: Storage nodes send the NURL to an introducer, in addition to the
 fURL for legacy Foolscap protocol. This is sent as an announcement upgrade
 so it supercedes existing announcement.
 3. #3783: The introducer sends NURLs to storage clients. INVARIANT: old
 storage clients can safely get and ignore NURLs. If this is not the case,
 some conditional logic needs to be introduced so old clients don't get
 NURLs. It seems like this will just happen automatically, and moreover the
 announcement is just a dictionary with random keys, so hopefully will Just
 Work once #3912 is done.
 4. DONE but disabled for now. The storage client understands NURLs, and
 use HTTP protocol instead of Foolscap when possible. See design doc for
 further discussion (QUESTION: is it actually possible to say "this furl
 and nurl are for the same server"? technically, maybe but not necessary
 given announcement upgrades).
 5. #4043. Currently the storage client caches per-server FURLs
 indefinitely. Or, the client may only have FURL, and not have introducer.
 For that situation the Foolscap protocol should grow a away for clients to
 get new URLs (`remote_get_version`?)

--

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