[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3457: The separate introducer servers represent unnecessary complexity in an overall Tahoe-LAFS deployment

[Tahoe-LAFS]

#3457: The separate introducer servers represent unnecessary complexity in an
overall Tahoe-LAFS deployment
------------------------------+-----------------------
     Reporter:  exarkun       |      Owner:
         Type:  defect        |     Status:  new
     Priority:  normal        |  Milestone:  undecided
    Component:  code-network  |    Version:  n/a
   Resolution:                |   Keywords:
Launchpad Bug:                |
------------------------------+-----------------------

Comment (by exarkun):

 Here's a more concrete elaboration of the latter idea above.

 The introducer-v3 manages a mutable directory on a grid (typically the
 grid for which it is the manager).  This is the grid service directory
 (GSD).  It encodes the mutable directory so that any single share from any
 single server in the grid is sufficient to reconstruct its contents.  It
 holds the writecap for the directory in secret and, for certain
 operations, shares the readcap.

 Into this directory, introducer-v3 will link readcaps for grid service
 announcement (GSAs) it wishes to share with any of its clients.  These
 readcaps yield objects containing, for example, a storage service
 announcement.

 A client is granted access to a grid by receiving two pieces of
 information.  First, the readcap for the GSD.  Second, one or more storage
 service fURLs.  The client connects to any one storage service using the
 fURLs supplied and reads the GSD and all GSAs.  Among the GSAs should be
 storage service announcements for all storage servers related to the
 introducer-v3 granting access.  At this point the client can connect to
 and use all of the necessary storage servers.  The client will monitor the
 GSD and GSAs to remain up to date with any reconfigurations which might
 take place (addition of new GSAs, removal of old GSAs, modifications to
 existing GSAs).

 A manual CLI for this workflow might go something like this.

 First, the operator of the introducer-v3 produces the two pieces of
 information required by the client:

 {{{
 $ introducer-v3 get-introduction-text
 <dir readcap>,<storage furl>[,<storage furl>,...]
 }}}

 Then the information is shared out-of-band with the client which enters it
 into their client:

 {{{
 $ tahoe create-node --introducer-v3 <dir readcap>,<storage furl>[,<storage
 furl>,...] ...
 }}}

 The given configuration is recorded for use when the node is running.

 When the node is started it:

 1. uses one of the <storage furl> values to connect to a storage service
 2. retrieves the GSD (using the <dir readcap>)
 3. fetches each GSA in the GSD
 4. rewrites its configuration to record all storage announcements found in
 the GSAs

 Thereafter, it periodically repeats steps 2-4 to ensure it remains up-to-
 date with any changes made by its introducer.

 A storage server can be taken out of service by unlinking its GSA from the
 GSD.

 {{{
 $ introducer-v3 remove-announcement <readcap>
 }}}

 A storage server can self-report configuration changes (such as its
 location hints) by rewriting its own GSA.  It takes care to encode the GSA
 so that every storage server known to it receives a share that is
 sufficient to reconstruct the GSA.

 A new storage server can be commissioned by:

 1. receiving access to the grid in the manner any client would
 2. writing its GSA to a mutable file
 3. sharing the readcap for its GSA with the introducer-v3
 4. the introducer-v3 operator links the readcap into the GSD

 {{{
 $ introducer-v3 add-announcement <readcap>
 }}}

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