[glue-wg] Thoughts on WLCG storage accounting use-cases

[Burke, S (Stephen)]

glue-wg-bounces at ogf.org 
> [mailto:glue-wg-bounces at 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.