glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@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