Hi Stephen,
On 31/07/12 02:58, stephen.burke at stfc.ac.uk wrote:
> Going through the GLUE 2 schema I just noticed that StorageShare has
> an attribute called AccessMode with type AccessMode_t which doesn't
> appear to be defined. The text is "An identifier for the type of
> access and usage allowed for this Share." which doesn't immediately
> ring any bells. Does anyone know what this was for?
dCache info-provider currently doesn't publish this attribute, pretty
much for the reasons you state.
From memory, the StoRM info-provider publishes something ... ah, but
not a terribly helpful value, though:
paul at vedrfolnir:~$ ldapsearch -LLL -x -H ldap://lcg-bdii.cern.ch:2170 -b
o=glue
'(&(objectClass=GLUE2StorageShare)(GLUE2StorageShareAccessMode=*))'
GLUE2StorageShareAccessMode|grep ^G|sort|uniq
GLUE2StorageShareAccessMode: to be defined
paul at vedrfolnir:~$
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?
Unfortunately, this doesn't quite work for dCache.
dCache has four potential uses for each disk-pool:
providing end-users with read access to files,
providing storage space for end-users to upload files,
storing files that are to be written to tape,
storing files that have been read from tape.
Each pool can have zero or more of these uses.
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".
However, there's a problem here. The ability of an end-user to use a
pool in any of these four modes depends on that user's VO (actually, it
rather more complicated than that, but lets keep things simple). For
example, a StorageShare might allow ATLAS and CMS to read data from the
pool, but allow only CMS to write into it.
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).
In GLUE v2.0, I hadn't made up my mind how to publish this information.
Given the multi-value of AccessMode, it would be possible to publish
multiple values, but this would loose the information about who is
allowed to write into the StorageShare (since it isn't necessarily all
VOs that have access to this StorageShare).
Another possibility is to publish multiple StorageShares for the same
collection of pools, one for each set of end-users. If all users of
this pool can undertake the same operations then only one StorageShare
would be published; otherwise, multiple StorageShare objects are needed.
Of course, I can take the Glue v1.3 route and publish the information as
OtherInfo attributes (at least, for now :-)
In summary, dCache doesn't currently publish any AccessMode and I'm not
sure if anything useful could be published here.
Thinking about the problem more generally, a better solution would be to
publish this information is in the MappingPolicy. End-users access the
storage system, so "AccessMode" might be something more appropriate to
MappingPolicy. This would "get around" the problem where the same
StorageShare may be accessed in different fashions by different end-user
groups.
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. MappingPolicy already has limited support
for this: the associations to one or more UserDomain objects. This
association describes how only end-users that are members of a
UserDomain may use the StorageShare.
So, in MappingPolicy the info-provider might like to describe how a
mapping only takes effect if the end-user satisfies certain criteria.
Here's some that would be useful for dCache:
o certain IP address(es) -- not necessarily a single net-mask.
o for certain end-users -- already supported with associations to
UserDomain objects.
o for certain protocols -- could be supported by introducing
associations to AccessProtocols?
o for certain portions of the namespace -- this would be quite
tricky to express accurately, since it may depend on the access protocol
(e.g., adding a prefix or removing a portion of the namespace) and it
might not be a complete sub-tree.
o for certain operations -- for dCache, the operations are read,
write, flush and stage.
HTH,
Paul.