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

[Ted Rolle Jr.]

Lat/Long\b\b\b\b\b\b\b\b spacetime coordinates avoid differences names, for
instance local spellings.
Example: Nuremburg/Nürnberg;

I believe the FIPS location standards apply only to the US.
Here's<https://secure.wikimedia.org/wikipedia/en/wiki/Federal_Information_Processing_Standard#Withdrawal_of_geographic_codes>
an
interesting read.  The FIPS standards are a moving target, changeable by
the stroke of a politician's pen.

Then, any desired human-readable information can be associated with the
coordinates.

General-relativityingly,

Ted

On Mon, Jan 16, 2012 at 14:47, Greg Troxel <gdt at ir.bbn.com> wrote:

>
>  I'd suggest that a plan of what is needed/wanted is the first step. How do
>  we do this? The wiki??? I know you main devs seem to use irc, but I'm not
>  in the US, so I can't easily contribute via that medium (i.e. tz issues).
>
> I'd say write up a plan and send it to the list.
>
>  As a first though to be knocked about:
>  - can we use the multi-introducer developments to manage node clustering?
>
> I don't see how that helps.  What I think is needed is:
>
> 1) Decide if we are going to trust storage nodes to express the
> variables that are correlated honestly.  I think it's at least near
> impossible not to trust them and make progress.
>
> 2) Decide if we are going to have each node express its correlation
> state, or put this in the introducer or similar.  I vote for per-node
> config.
>
> 3) Design a mechanism by which a server node can advertise some
> properties to clients, like "location=US/Massachusetts/Cambridge/BBN".
> Display this in the WUI, and make it obtainable in the CLI.
>
> 4) Design a first-cut protocol for encoding what we care about into
> properties.  I sent a zeroth-cut proposal in the previous paragraph :-)
>
> 5) Design a way to take a list of nodes with their location properties
> and make the peer selector/balancer spiffier.  I think this is replacing
> 'shares.happy' with a more nuanced claim.   Perhaps just have a way for
> people to write their own rules and link it in, and we can experiment
> for a while.   A possible rule is "on at least 4 servers that differ in
> city".   Or "at least 5 servers, with at least 3 cities, and no 2 of
> which share a site".  This rapidly gets messy.  But it can be
> individualized code as long as it's easy to write.
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>


-- 
GPG/PGP public key: B07F9AAE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120116/7f94eae7/attachment.html>