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

[Burke, S (Stephen)]

Paul Millar [mailto:paul.millar at desy.de] said:
> 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.

The requirement isn't necessarily that they never change, but that there
may be consequences if they do. The same is often going to be true for
any URL/URI - for example desy could change its domain name from desy.de
to desy.org, but there would be many consequences, e.g. that lots of
email addresses and web links stored all over the world would become
invalid. I think this is an underappreciated point in fact, e.g. there
are still plenty of links around that point to http://uimon.cern.ch even
though it was moved a couple of years ago (at least the redirection is
still alive).

  Being more of a purist I could argue that if you change the unique
name of something it in fact becomes a different thing that just happens
to share some of the properties ... however, in practice most Glue UIDs
are not that critical, probably SE and Site IDs are the most important
to preserve (and of course the VO names).

> 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.

How would that help? You still have to ask the SRM for a TURL, so what
would you do with the information? (For a classic SE it's different,
there you do need the endpoints.)

> > 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"?

RunTimeEnvironment is an attribute of a CE used to publish arbitrary
information about installed software, much like the OtherInfo
attributes. VOs need to be able to add their own tags to advertise
VO-specific software installations, so the CE has a gridftp server to
allow them to deposit the information where the info provider can find
it. Potentially you could have the same kind of thing on the SE.

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

That server is on the RB, but that is indeed another example of a
gridftp server not used for generic data storage.

Stephen