[Federated-fs] Discussion of FSN resolution: what is required vs what is expected

[Daniel Ellard]

A few points related to FSN resolution came up in the conference call, so I
think it's a good idea to discuss the current draft requirements and
different methods that can satisfy those requirements.

The first requirement is that an FSN must convey two pieces of information:

1. The NSDB that "owns" the information about the FSN.

2. The "junction key" that identifies the fileset and is used by the "owner"
NSDB as the key for information about that fileset.

This leads to the simple resolution mechanism outlined in the current draft:
to find the FSLs for an an FSN, use the FSN to find the NSDB, and then ask
the NSDB for the FSLs for the junction key represented by the FSN.

Given the current requirements and definition, this resolution method MUST
work.  However, there is no requirement that this is the resolution method
that must be used!  This method is the fallback when all else fails
(although for a simple implementation, it could be the only method).

For example, in a clustered system, all servers in the cluster might funnel
their requests through a local proxy NSDB that caches the responses from the
owner NSDBs.  If two servers request the same resolution within a short
period of time, then the first might have to go through to the owner NSDB,
but the second could be answered from the cache.  Cache entries would be
marked stale and invalidated after a given period of time elapsed.  A
callback could be registered at the owning NSDB for FSNs of local interest
(i.e., the FSNs present in junctions within the section of the namespace
implemented by the server), if that turns out to work better than polling.

There are many solutions to this kind of problem, but I won't claim to know
enough about the parameters of the system -- how many nodes, how fast the
FSN bindings change, etc -- to pick the winner.  I don't think we'll know
for sure until we actually build one, but we need to make something flexible
enough that the real behavior of the system can emerge.  We don't want
something that admins only use in limited ways because those are the only
ways that the system works!

One solution that doesn't satisfy the current criteria is to use a
hierarchical system, similar to DNS.  The resolution method starts with a
local NSDB (or similar service) and escalates up through the hierarchy until
the value is found, and then the results are cached along this path.  The
problem with this approach is not technical -- we know how to do this.  The
problem is that I don't see a way to map a hierarchy onto a federation of
peers.  The federation member(s) that hosts the root(s) of the hierarchy
have an asymmetric relationship with the other members.  Instead of a
junction being a relationship between two federation members, now additional
federation members may be required in order to traverse a junction.

You may note the arguable contradiction (or hypocrisy) that I am opposed to
using intra-federation DNS-like resolution for FSNs, but I am perfectly
happy assuming that the system uses DNS to perform many federation-oriented
tasks, such as finding NSDBs or naming the servers on which filesets are
implemented.  This is because the DNS framework is a superset of any
federation -- the root servers (and probably most of the ancestors on the
way to the root) are independent of and/or outside of the federation.

Please add your thoughts...

What do we need to require in order to make a flexible resolution protocol
possible?

Thanks,
    -Dan