[glue-wg] Some thoughts on storage objects

[Burke, S (Stephen)]

Felix Nikolaus Ehm [mailto:Felix.Ehm at cern.ch] said:
> Generally, I think that comparisons between Glue 1.x and 2.0 
> are helpful
> only to some extend. Concepts of 1.3 do not fit into 2.0 and therefore
> the base for comparisons is not really given.

That may be true, but it should at least be raising a flag to look more
carefully. In this case the Share as defined in the current draft
*can't* be something that could be shared between VOs, because it has
Tag as an attribute and the Tag names (space token descriptions) are
VO-specific, so if people are conceiving it as something that can be
shared (i.e. an SRM space or equivalent) then something is wrong. (For
classic SE use the same applies to the Path, typically different VOs
would have different Paths even if the space is shared). That also
suggests to me that ExpirationMode probably should not be in the Share,
although I'm not entirely sure how SRM works - is the ExpirationMode a
property of a space, or can it be VO-specific like the Tag?

> For example, all sizes of mapping policies pointing to one share might
not
> sum up to the total size of the share.

Can you give a concrete example? To me this doesn't make sense: an SRM
space is a single entity, and anyone authorised to use it shares that
space. The only way you could subdivide it would be to reserve
sub-spaces within the space, and then you'd need a more complex
description.

  If you're saying that the *used* space could be subdivided according
to who actually owns the files then I think that's the wrong way to go,
then you're getting into detailed accounting which is not the purpose of
Glue (among other things the owners don't necessarily map to the rules
in the MappingPolicy).

> The enviroment linked to the capacity was introduced to give an
> summarized stats about the total spaces of all types of enviroments.

Is there actually a good reason to want to know that? To me it's still
much more useful to have the information either per space, or summarised
for the entire SE. In WLCG it makes less difference anyway as we only
use three classes - the only real difference is having disk space usage
separated between Disk1Tape1 and Disk1Tape0 as opposed to the combined
value you get for the whole SE. What is the use case to need that? At
the very least I think you'd want it broken down by VO - that was the
compromise we officially ended up with for 1.3 although personally I
still think it's a mistake.

> If you mean by SRM space something which is accessible via a
> SpaceTokenDescription then the first way is to put it into the share.

We should be clear about this: spaces are accessible by space token
descriptions, but that is *not* unique: one space (token) can have many
space token descriptions (typically one per VO).

> All associated MappingPolicies would then see the same 
> 'default' STD and
> path (except, you'd specify a own 'non-default' path/STD in a
> MappingPolicy).

??? I don't think I understand that at all. A Mapping policy is
basically an ACL, i.e. something like VO:atlas or
VOMS:/cms/Role=Production. I wouldn't be inclined to say that
MappingPolicies "see" anything, it's the other way round: a share sees
(or has) a mapping policy, i.e. a rule to say who can use it. (Would you
be inclined to say that some particular unix file permission "sees" all
the directories which have that permission?)

> I understand your use case but is this an information system use case
> for the future? I would say that this is rather a deployment 
> issue than
> something which needs to be published so that the 
> middleware/user has to take care of. 

Actually it's a use case for the past, we just never satisfied it! For
classic SEs it is in principle something the middleware needs to know
about. Say you have a VO Path of /data/atlas, and you publish a free
space value for that. If you actually have two disk servers mounted at
/data/atlas/mc and /data/atlas/data then that information isn't enough,
e.g. /data/atlas/mc may be full even if the total free space is still
large.

  Whether we need something similar in the SRM world, i.e. whether you
need to know the underlying hardware situation as well as the logical
"space token" view I'm not sure - but if we don't then why are we
considering publishing at least some of it, and why are we having this
discussion about completeness/covering at all?!

Stephen