Re: resources

we do this in Inferno using an attribute/value file server, registry(4).
it's not specific to grids, let alone processing nodes.  it is perhaps
generally along the lines of (say) Peterson's various yellow pages
suggestions years ago--nothing to do with Sun's or British Telecom's.--
except that it's simpler than his more general designs and implemented
as a file service.  entries are made by creating files and writing a
description: a set of space-separated words, interpreted in pairs as
attribute, then value.  there is no punctuation.  an `index' file gives a snapshot
of current entries, one per line; a `find' file accepts a write containing
a query or constraint (attr value ... where * is any value) and subsequent reads
return a snapshot of matching entries.

there's nothing to say what the scope of a registry is: it might
describe things at a given node, at a site, or for a confederacy;
it can be used recursively (registry entries that describe
other registeries or even itself); its contents might represent
an edited subset of a collection of other registries, for instance
using applications that forward entries.

i'd say: don't rely on Internet addressing though for service addresses.
that might work within a site but, for instance in our case, it doesn't work
even across the networks connecting our office network and our
home network.  NAT in various flavours renders any attempt to
specify addresses `directly' unworkable (and we aren't even dealing
with NAT hierarchies).  worse, even domain names can't be relied upon,
(and even if they did, NAT means the port numbers might not work).
we're experimenting with some alternatives.

i think it's probably also a mistake to obtain things like load averages
in this way, although it might be a useful repository for historical
data.  Peterson suggested a method for handling dynamic attributes such as load
but even that doesn't seem to give the right result in this application
(at least for what we're doing at Vita).