[tahoe-dev] server selection Re: Node correlations - [Was] best practice for wanting to setup multiple tahoe instances on a single node

Zooko Wilcox-O'Hearn zooko at zooko.com
Tue Jan 17 18:21:43 UTC 2012


Folks:

There is a *lot* of interest in this topic. A lot of people seem to
think Tahoe-LAFS does everything they want except that it doesn't give
them a way to do this.

I hope this means somebody is about to volunteer to implement it! :-)

Olaf:

Yes, I think if we had a file describing which storage servers should
be used and/or what description (location, tags, whatever) is
associated with each storage server, then it would be a useful
improvement to start distributing the contents of that file from some
service. Then you can configure multiple gateways one time to get
their configuration from that service from then on, instead of
reconfiguring each of them each time you change your ideas about the
servers. That service is called a "blesser" in the tickets mentioned
below, because the gateway refuses to use a server unless that
server's public key comes with a "blessing" signed by the blesser's
private key.

However, I suggested the simpler "hosts file"-style approach for
starters because I feel like there's a lot I don't understand about
this, and that experimentation with real situations will make it
clearer.

#295 and #466 is laying the groundwork for a future implementation of
a "blesser". It is a cool idea -- instead of connecting directly to
the blesser and asking it to give you the descriptions the known
servers, you instead listen to gossip in a p2p style, distributed by
introducers. Any gossip which is signed by the blesser's private key,
you treat as valid descriptions of servers.

So basically there are two parts of this project. The first part is to
make a way to conveniently communicate information about what servers
have what properties from system administrators to some set of
gateways (including the property "this server should be used at all
for anything"). The second part is to make it possible for
administrators to specify some sort of policy about what servers
should be use to store what shares during an upload, given that the
servers have certain properties, as provided by the first part.

Now, I have a fairly good idea of how the first part should be done --
by following Brian's lead and helping him finish the longstanding
ticket #466. This will eventually enable you to specify which servers
should have which properties. It will eventually enable such things
as: since you're the gatekeeper of the volunteergrid that I am on, I
will treat any storage server signed with your private key as being a
part of my volunteergrid. Also things such as: I can mark a certain
storage server as being in a certain rack, colo, network(s), state,
government, continent, family, and company.

I have a much less clear idea of what shape the second part will take.
That's the topic of discussion of this thread, if I understand it.
That is: given that I now know the rack, colo, family, and government
of each of the storage servers on my volunteergrid, then which ones
should I use for uploading which shares to? See
https://tahoe-lafs.org/trac/tahoe-lafs/wiki/ServerSelection for a list
of desired policies that different people have mentioned at different
times.

Therefore, I hope people who are really keen on this topic will start
with a locally-managed text file and experiment with part two -- how
to express and enforce policies -- because I want to learn from their
experiments. I already have a better idea about how that
locally-managed text file could eventually be complemented by or
replaced by part one (tickets #68/#295/#466). Part two is described in
ticket #467.

Olaf's suggestion of JSON and some scripting language such as Guile is
the sort of thing that could be an answer to this question, I think.

Regards,

Zooko

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/68# implement
distributed introduction, remove Introducer as a single point of
failure
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/295# distributed
authorization of access to nodes
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/466# extendable
Introducer protocol: dictionary-based, signed announcements
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/467# allow the user to
specify which servers a given gateway will use for uploads


More information about the tahoe-dev mailing list