[glue-wg] More comments on the draft spec.

[Paul Millar]

On Friday 16 May 2008 18:31:40 Burke, S (Stephen) wrote:
> > Paul Millar said:
> > So, it seems we have a requirement for IDs or LocalIDs to be
> > persistent over time.  This should be stated somewhere, probably
> > in section 3 
>
> You're right. For UniqueIDs there may be other requirements, because
> they may be stored in external services like catalogues or databases
> (e.g. consider the site names, which start in the GOCDB and propagate
> all over the place - not trivial to change).

Actually, I'd say that storing the UniqueIDs in something like a catalogue 
is "broken" client behaviour.  I certainly feel we (GLUE) should *not* make 
it a requirement that UniqueIDs never change in order to support this broken 
behaviour.

It's reasonable to require information providers to provide consistent 
UniqueIDs for (choosing a duration out of the thin air) an hour.  Supporting 
constant UniqueIDs for longer periods would be better, with the expectation 
being that (for a production system) LocalIDs remain constant for many (many) 
days.

(Stating the same idea, but without choosing a random number: an object's 
UniqueID value should remain constant for a period far greater than the 
latency of the underlying information system under normal operating 
conditions.)

However, LocalID values may be derived from the system configuration, which 
might change in a non-trivial way.  If such a system-change takes place, it 
may prove impossible to maintain LocalIDs, so the values *will* change.  This 
is unavoidable.

Of course, clients are free to store these values wherever they wish (we can 
hardly stop them!), but they should be aware that LocalIDs cannot be 
guaranteed in perpetuity.  If the values are stored in a catalogue, then 
their software must be prepared for these values to change at an unannounced 
time in the future.

Ideally (IMHO) clients should always derive LocalIDs by querying the 
underlying system against known values of properties.  This process may be 
optimised by (for example) caching LocalIDs, but if so, these caches are 
understood to be volatile and not recorded somewhere permanent, such as a 
catalogue.

This is why I feel there should be a clear statement of this somewhere in GLUE 
specification.


> > It's a little unclear why we have both StorageAccessProtocol and
> > StorageEndpoint since StorageEndpoint can represent access protocols.
>
> Well, it isn't entirely obvious that StorageEndpoint *can* represent
> APs, that was one of my questions...

For LAN access, you might want to advertise which machines and from which port 
the protocol is available (dcap, gsidcap, xrootd, rfio), or you might not 
(AFS, NFS, Luster, GPFS).

However, properties like hostname and port information seems to be missing 
from the StorageAccessProtocol entities.  If you want to publish these 
properties then currently one must use a StorageEndpoint.


> However, you would still like to have the list of protocol types which are
> supported.

Sure.

> Also there could be other complications, for example an SE might have a
> gridftp server for reasons other than it being an accessprotocol (e.g.
> the CE currently has one to allow RTE tags to be published ...)

Sorry, what are "RTE tags"?

My knowledge of CEs is rather limited, but I thought the current CEs have a 
gridftp server to allow transfers of user sandboxes.

Cheers,

Paul.