[glue-wg] Suggestion for splitting the StorageShare.

[Maarten Litmaath]

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 at ogf.org
>>http://www.ogf.org/mailman/listinfo/glue-wg
> 
> 
>