| 4 | | * the set of storage servers that are considered for peer-selection should |
| 5 | | come from a config file, with one server per line, of various types |
| 6 | | * one entry type means "ask the introducer", perhaps with some parameters |
| 7 | | like "only accept servers that are blessed by the following key" |
| 8 | | * if this file doesn't exist, it defaults to asking the introducer |
| 9 | | * one entry type (or introducer tag) is used to point at a storage server's |
| 10 | | "login FURL" instead of a fully-powered reference. (we need a better |
| 11 | | name for this object). This is the object to which the client will pass |
| 12 | | credentials and/or signed certificate chains. |
| | 6 | I'd like to have a section in the client's tahoe.cfg which lets it |
| | 7 | specify the servers available for storage. In contrast to #573 (which is |
| | 8 | about runtime/per-upload specification of which servers to use, out of |
| | 9 | the set provided by the introducer), this ticket is about boot-time |
| | 10 | configuration of the available set, potentially replacing the |
| | 11 | Introducer-provided list. |
| 14 | | When the peer-selection process needs server references, the client should |
| 15 | | ask the login FURLs for server references, performing credential negotiation |
| 16 | | if necessary. The client should cache the results for later use, so ideally |
| 17 | | the negotiation only needs to take place once. |
| | 13 | My thought is that the tahoe.cfg should have a section that specifies a |
| | 14 | list of servers to use. Then another tahoe.cfg setting should have a |
| | 15 | flag which says "use the Introducer to populate this list", and the |
| | 16 | default configuration would use the Introducer. This latter section |
| | 17 | would also have a place to configure the #466-style "blesser" (a pubkey |
| | 18 | which tells the client to only accept server announcements which have |
| | 19 | been signed by the matching privkey). |
| | 21 | This would also make it possible to configure alternative server types. |
| | 22 | The first such server type I'd like to add is an S3-based server. |
| | 23 | Regular servers would be defined with a FURL; S3 servers would be |
| | 24 | defined with a service URL and a set of authorization secrets. |
| | 25 | |
| | 26 | The syntax I'm thinking of would look like this: |
| | 27 | |
| | 28 | {{{ |
| | 29 | [client-server-selection] |
| | 30 | server.X.type = tahoe-foolscap |
| | 31 | server.X.nickname = alice |
| | 32 | server.X.furl = pb://... |
| | 33 | server.Y.type = tahoe-foolscap |
| | 34 | server.Y.nickname = bob |
| | 35 | server.Y.furl = pb:// |
| | 36 | server.Z.type = s3 |
| | 37 | server.Z.nickname = aws |
| | 38 | server.Z.url = http://... |
| | 39 | server.Z.creds = ... |
| | 40 | server.Z.num_shares = 3 |
| | 41 | use_introducer = False |
| | 42 | permute_serverids = False |
| | 43 | }}} |
| | 44 | |
| | 45 | The {{{server.*}}} lines would basically define a list of dictionaries |
| | 46 | (the "X" and "Y" strings would be discarded after tahoe.cfg is parsed). |
| | 47 | |
| | 48 | The "use_introducer=False" line means that the client shouldn't bother |
| | 49 | talking to the Introducer. If it were True, the client would connect to |
| | 50 | the introducer and add whatever servers it knew about to the list. |
| | 51 | |
| | 52 | The "permute_serverids=False" line means that the client shouldn't |
| | 53 | permute the serverlist on each upload. Instead, it should assign 1 (or |
| | 54 | num_shares=) shares to each server in the order they appear in this |
| | 55 | list. The total-shares "N" value ought to equal the number of servers |
| | 56 | (or rather the sum of the num_shares= values). |
| | 57 | |
| | 58 | Having permute_serverids=False in the tahoe.cfg, rather than provided on |
| | 59 | a per-upload basis (as in #573) might prove more usable. It might be |
| | 60 | more appropriate for a fairly stable grid though: one in which new |
| | 61 | servers are not being added very frequently. |
