Hi Stephen, Thanks for the comments. I've added some,too :-)
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.
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. Its more important to agree on what we want to express. In case of the VOInfo the information can be expressed by the StorageMappingPolicy which describes how a VO may utilize a Share representing storage space. Both keep StorageCapacity info to give opportunity to distinguish more than one viewpoint of accounting. For example, all sizes of mapping policies pointing to one share might not sum up to the total size of the share. On the other hand: All associated mapping policies generally should see the SAME free space as specified in the Share. The Share also keeps capacity information in order not to run over all mappingpolicies and count the (e.g.) usedSizes. There is also the case of having no free space in the associated MappingPolicies but some free published in the Share - not sure if this is makes sence. However, I think that GLUE should not judge these specialities. They should be treated by the instances which use the info.
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?).
The enviroment linked to the capacity was introduced to give an summarized stats about the total spaces of all types of enviroments. This does not neccessarily mean that all used spaces of the linked shares should sum up to the (total) used space of the enviroment. On the opposite it would be odd if you would publish a total size for the environment which is lower than sum of the associated shares. This is a known problem. If you mean by SRM space something which is accessible via a SpaceTokenDescription then the first way is to put it into the share. 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).
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.
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. In the case obove you would store on the server side all incoming files under /data/atlas on server1, /data/cms/ under server2, etc.. Can this be done like this or am I completly wrong? Cheers, Felix _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg