Hi Laurence, Laurence Field wrote:
On further investigation of the Storage Schema an unmet use case has been found.
Use Case: Consider two VOs who use two different paths to access the same StorageShare or alternatively one VO who can access the same StorageShare via two different paths. Where there could be an asymmetry with the ACLs for the SRM v2.2 space and the Path.
The latest schema would require a StorageShare to be instantiated for each combination of path and SRM v2.2 space ACL, leading to n*m storage shares duplicating a great deal of information.
it is better to state that the use cases are supported, but at the price or redundancy of information in certain situations. This was discussed several times and a final choice was made around a month ago. We opted to go for simplicity at the cost of redundancy. The criterion for choosing among the different approaches was to privilege simplicity in querying the information even though redundant data may need to be published in some situation. There is no real best solution. As Maarten described, you may have either big VO's with their own dedicated shares (so no redundancy) and small VO's sharing the same storage shares (redundancy occurs). For a while, we had a more "normalized" schema. The price to pay is a complexity of relationships and an higher cost at selection time (thing about making all the combinations in order to find out the best solution). And also keep in mind that representing associations does have a fixed cost of two attributes. If you really want to discuss again this, you should first draw a complete picture with all the entities, relationships and multiplicity (e.g., what about Capacity-like entities?). Otherwise, it may look simpler but it isn't when you go deeper into the details. Cheers, Sergio
The suggested solution is to split the StorageShare into the StorageShare and StorageEnvironment where there is a one to many relationship between the Environment and the Share. Both entities inherit the ACLs from the AccessPolicy
StorageShare LocalID Path Tag
StorageEnvironment LocalID ServingState AccessLatency RetentionPolicy ExpirationMode DefaultLifeTime MaximumLifeTime
At the same time this allows the AggregationID to be removed.
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
-- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi