[glue-wg] StorageSharePath multiplicity requested by Atlas

Paul Millar paul.millar at desy.de
Thu Jun 7 05:42:08 EDT 2018


Hi Alessandro,

On 07/06/18 10:33, Alessandro Paolini wrote:
> some time ago, after collecting the feedback from the Atlas community, 
> you proposed to change the multiplicity of StorageSharePath from "0..1" 
> to "0..*"

Yes, that could be -- it's been a while now :)

> This is the Stephen's comment about this change:
> "it still isn't clear to me that multiplicity * makes sense. This is 
> supposed to be a default path, if there are several you don't know which 
> to use.

IIRC, the idea is to describe how writing into different paths would 
consume capacity from the same StorageShare.

Perhaps a concrete example would help.  Imagine a normal Linux/Unix 
machine that has NFS mounted a remote server.  The same server could be 
mounted at two different places in the namespace.  Writing into either 
path would consume capacity on that NFS server.

In reality, this isn't about NFS servers, but rather that a particular 
storage resource may be writeable through different two paths that do 
not share a parent-child relationship; for example, /data/tape/type-A 
and /data/tape/type-B.

In dCache, user write requests may target some subset of all available 
capacity.  The namespace is one way of choosing which resources are 
eligible for storing data, somewhat similar to how, on a Linux machine, 
writing into a particular directory might target an NFS server or a USB 
drive.

> Also if there is any software using this (possibly not) it would expect 
> a unique result and probably break if it got more than one.
> If this is really wanted I would say add a new multivalued attribute 
> Paths or OtherPaths."
 >
> I agree with him that adding a specific multivalued attribute would it 
> be better than modifying the multiplicity of the existing one: would you 
> agree as well?

Yes, fair enough.

I have a slight preference for "Paths" over "OtherPaths", since 
OtherPaths suggests the value of Path is somehow canonical or preferred, 
which (I believe) isn't the intention.

We should also take care to define the relationship between Path and Paths.

For example, if there is a single path, is this published under Path, 
under Paths, under both?

If there are multiple paths, should nothing be published under Path?  or 
should some preferred path be published?

Cheers,

Paul.


More information about the glue-wg mailing list