[glue-wg] Some thoughts on storage objects

[Burke, S (Stephen)]

glue-wg-bounces at ogf.org 
> [mailto:glue-wg-bounces at ogf.org] On Behalf Of Paul Millar said:
> > >  StorageSpaces must have one or more associated StorageCapacities.
> > |         ^^^^^^
> > |         Shares
> 
> Yes, I'm not sure what happened there: too many words 
> beginning with "S", I guess.

Well, possibly more than that ... I think there may be a
misunderstanding here. In the current (1.3) schema there is a general
intent that SAs map to spaces (space tokens) - that was somewhat
controversial but seems to be broadly right, e.g. look at what RAL is
currently publishing for its SRM 2s (one SA per space token) which to me
seems entirely natural. In any case, VOInfos do *not* map to spaces,
they map to space token *descriptions* (Tags) - potentially you could
have one space shared by multiple VOs, each of which would have their
own Tag (and/or Path) for the same space.

  For Glue 2 the VOInfo seems to have turned into the Share, at least
judging by the attributes. However, that means that a Share is *not* a
space, and your slip above seems to suggest that that's the way you're
thinking. If several VOs shared a space there would be several Shares -
basically one Share per MappingPolicy, not one per space, although a
MappingPolicy might consist of multiple rules. 

  If anything represents a space in the SRM sense it would be the
Environment - but as I said in the previous mail that's become a bit
unclear since Environment now has no real attributes, just a type which
represents a storage class, so we're left with the ambiguity (which we
also ended up with in 1.3) of whether one Environment represents all
spaces of a given class, or whether you have one per space (or maybe
something else?).

> Somehow, accurately describing what overlapping and 
> incomplete StorageShares means takes a lot of words!

Maybe because we are trying to represent distinct concepts with the same
words, and maybe the same Glue objects? There are at least two different
underlying concepts: physical disk and tape systems, and logical spaces
(reservations) which may span many instances of the physical storage,
may be contained within them, and may be shared between VOs or not. (And
which might perhaps be nested ...) This was always a problem in glue and
we never dealt with it. For example, take a classic SE with a file
system organised like:

/data/atlas
/data/lhcb
...

each of which would be published as one SA. However, in terms of the
physical disk servers you might have one big server mounted at /data, n
smaller ones mounted at /data/atlas, /data/lhcb, ... or m even smaller
ones mounted at /data/atlas/mc, /data/atlas/cosmic/, ... or any
combination of those, and we had no way to describe those variations in
the schema. With SRM we no longer worry about that level of detail, but
the general distinction between physical and logical space is still
there.

Stephen