glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said: MappingPolicy objects that act as links between StorageShare objects and UserDomain objects.
One point I'd make is that the UserDomain objects are a bit of a red herring in all this, when thinking about authorisation it's better just to focus on the Policy objects. Policies will generally refer to VOs and the UDs can publish information about VOs, but that's pretty much irrelevant to using the Policies. The main reason for having multiple Policy objects attached to the same Share is that they could declare policies in different authz *schemes*. For a single scheme (e.g. I expect to have a "glite" scheme for the EGEE standard use with VOMS) you would generally only expect a single policy object. In the CE discussion I raised the possibility of having multiple MappingPolicies within a single scheme to give the possibility to express an ordered priority between the Rules, since Rules within an object have no ordering, but I think that was rejected. So I think the answer is that for the normal case, e.g. an SE within EGEE/LCG, you will just have a single MP with a set of authz rules (unordered) looking much as it does now, e.g. VO: cms VOMS: /atlas/Role=production ...
complication for the clients. We can remove it by changing either the Share: MappingPolicy.ID multiplicity to "optional" (0..1)
No, it needs to be * to support multiple schemes, but in general a client would only understand one scheme so it only needs to consider (at most) one of the MP objects. I think we explicitly don't define the expected behaviour if a client can understand more than one scheme. Technically you could publish multiple objects with the same scheme, but in the absence of extra rules it would be semantically identical to having a single object, and probably the scheme definitions should normally say explicitly that there should only be one object.
(Mapping)Policy: UserDomain.ID multiplicity to "required" (1).
There is no guarantee that UD objects are published at all, and in EGEE/LCG my expectation is that they won't be.
It might be worth adding another optional attribute, to allow accounting for (temporarily?) off-line storage. For example, adding:
UnavaliableSize UInt64 0..1 GB Size of storage extent that is
Yes, I think we need to add something new to allow for this distinction between "installed" and "currently available", but we should probably have a dedicated phone meeting to discuss what's needed. Stephen -- Scanned by iCritical.