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

Greg Troxel gdt at ir.bbn.com
Mon Jan 16 20:42:36 UTC 2012


Nathan Eisenberg <nathan at atlasnetworks.us> writes:

>> True, but the paranoid will not want to publish them.  (And if you're
>> not paranoid, why are you using tahoe-lafs?)
>
> Don't forget the service provider/datacenter model should be accounted
> for in the naming convention - ie, these two nodes are sitting on top
> of eachother in the same cabinet, or are two blades in the same blade
> chassis, or they live on a virtualization cloud and 'move' from
> physical processing node to physical processing node.

Agreed.  So I think grids that deal with that will want to define how to
express it, and write rules to parse.   I think solving the general case
is too hard.

>> True, but the paranoid will not want to publish them.  (And if you're
>> not paranoid, why are you using tahoe-lafs?)
>
> Because it's cool / offers great data survivability / is fairly unique
> in its implementation.  There are plenty of deployed Tahoe grids that
> are internal-use-only out there, where the servers are all 'trusted'
> (in that a 3rd party is no more likely to get control of a storage
> node than of the introducer or gateway).

True - I was partly kidding.  But giving a symbolic name when the
recipient doesn't need to know the coordinates is a least-privilegy way
of operating, and putting fine-grained location data when it isn't
necessary seems to go against the grain.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120116/fdeec8eb/attachment.pgp>


More information about the tahoe-dev mailing list