Paul Millar [mailto:paul.millar@desy.de] said:
GLUE2StorageShareAccessMode: to be defined
That seems unlikely to be a valid value!
To be honest, I've forgotten what was the intended use for this attribute. Could it be so a pool that is meant only for staging data from tape, or as a read-only cache, may be marked as such?
In Flavia's document for glue 1 we have Capabilities of scratch and stage, so perhaps that's what we had in mind, but I'm not sure why we didn't at least define a few values. I searched the wiki and my mail archive and found nothing, so it seems we just overlooked it. If we have no uses at the moment I suppose we can just leave it for future definition, but it might be nice to add some kind of comment.
Where it gets complicated is that the usage can depend on many things: from which IP address the client is connecting, which protocol is being used and in which directory the file is located. Selection based on the end-user's VO is supported from the last point; for example, directories that only ATLAS users may access (due to ownership and permissions in the filesystem) may be tagged, which allows for selecting special pool as "ATLAS pools".
At some point we have to decide what's practical to publish and use. If the setup is too complex it may just have to be agreed out-of-band that a particular VO needs a particular configuration, or else you publish a single tag for a whole bundle of attributes that a VO can interpret. That's analogous to the fact that we don't attempt to publish every installed rpm for CEs - VOs can either ask for certain things to be installed as a condition of supporting a VO at all, or they can publish RunTimeEnvironment tags to identify CEs with support for specific things of interest to them.
For example, a StorageShare might allow ATLAS and CMS to read data from the pool, but allow only CMS to write into it.
Does that kind of thing happen in practice? I would have thought that usually atlas and cms pools would be kept separate.
In GLUE v1.3, I published this information as dCache-specific GlueSACapability attributes. A list of VOs that have specific access rights. The attribute values have the form dCacheCan<op>=VO:<vo-name> (e.g., dCacheCanStage=VO:ops).
Does any client use that information?
In general, what's missing in MappingPolicy is the ability to specify more predicates. These are conditions that must be satisfied for the MappingPolicy to take effect.
You can potentially define a more complex syntax for the PolicyRules, as long as you can get it all into one line. However I don't think it's ideal to have dcache-specific things, the general idea is for all SRM systems to be treated in the same way. Anyway I think this should be driven by practical need, rather than trying to publish everything just in case it might be useful. Also I think you should at least have a toy algorithm for how a client might use it - if it's more than a few lines of pseudo-code it's probably too complicated to be usable. Stephen -- Scanned by iCritical.