Ciao Sergio,
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.
Note the asymmetry! The ACLs for the name space need not be equal to those of the SRM v2.2 space. Putting both kinds of ACLs into a single StorageShare object implies they _must_ have different schemes. If they are in different objects, they can have the same scheme, e.g. "posix".
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.
Yes, this seemed the best compromise at that time. Now, however, we have another reason for splitting off the common attributes into a separate object that is _only_ linked to the StorageShare.
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.
StorageShare * --> 1 StorageEnvironment Capacity can just stay with StorageShare for simplicity. It will then keep reporting the numbers as experienced by the FQANs mentioned in the ACL entries. Thanks, Maarten
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