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

[Paul Millar]

Hi Stephen,

On Friday 19 December 2008 12:46:56 Burke, S (Stephen) wrote:
> > 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.

Yes, publishing a MappingPolicy object certainly a minimum requirement and 
the "easy bit" :-)

> Policies will generally refer to VOs and the UDs can publish information
> about VOs, but that's pretty much irrelevant to using the Policies.

Sure, one can publish a Policy object without linking it to a UD, but that may 
place additional burden on clients when they attempt to do service selection.

Policy objects, in general, represent some form of access control that allows 
end-users it.  Without linking the Policy object to a UserDomain, one forces 
the GLUE client to understand the authorisation schema to decide whether 
members of the UG are allowed to access it.


>  The main reason for having multiple Policy objects attached to the
> same Share is that they could declare policies in different authz
> *schemes*.

Ah, that makes sense.

> 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

It would be nice to have this in the document.  Perhaps something like:

	Multiple MappingPolicy objects MAY refer to the same Share object.  If so,
	these MappingPolicy objects SHOULD have different authorisation schemata.


> > 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.

OK.

> 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.

Aye, see my suggestion above.


> > (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.

Ah, OK ... but see my other email and the (open) question of doing service 
selection without the client understanding the authorisation schema.


> > 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.

Yup.

Cheers,

Paul.