[glue-wg] Suggestion for splitting the StorageShare.

[Paul Millar]

Hi Stephen, others..

On Monday 28 April 2008 17:47:20 Burke, S (Stephen) wrote:
> glue-wg-bounces at ogf.org
>
> > [mailto:glue-wg-bounces at ogf.org] On Behalf Of Maarten Litmaath said:
> > 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 I've understood what you're saying I don't think the namespace ACLs
> should be in GLUE at all, the granularity is too fine

Moreover, the ACL semantics will (in general) be filesystem-specific.  To 
illustrate this, consider:
	what is the default policy for user X (or, users undertaking role Y) if they 
have no listed ACE for operation Z (default allow or default deny)? 

	What are the allowed ACE operation types (how do I distinguish between an SE 
that doesn't understand "restage" operations vs a user that happens not to 
have an ACE for "restage", so the default policy should apply)?

	If conflicting ACEs are available (user X, under role Y is attempting 
operation Z; X is deny doing Z, Y is allowed to do Z), what is the policy? 
(default deny, default allow, use default policy for operation Z, ...)

	Should the ACL be interpreted as an ordered list (first match wins) or some 
other policy (try all "denies" then all "allows" then use default, first 
match wins; or, try all "allows" then "denies" then use default, first match 
wins; or, ...)?
	...  etc ...

The point isn't what you or I might think of as "correct" behaviour, just that 
different people (and different filesystems) will interpret these questions 
differently.

Perhaps GLUE can only publish ACLs if it also publishes some identifier that 
specifies how to interpret the ACLs.  The identifier namespace could be a URI 
(to be general), or simply list the filesystem, although that's sub-optimal 
as multiple filesystems might implement the same ACL.

Basically, I don't believe GLUE can publish meaningful ACLs without the schema 
becoming sufficiently complex that no one could publish the information 
correctly, or correctly interpret the information they receive.

> > 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.
>
> Well, if we do it properly I think we'd need to split the Capacity into
> pieces - the Used space would be per VO (or FQAN), but the Total and
> Free space are by definition shared and hence should be in the Share
> (Reserved may need more thought).

Yup, sure.  This comes from the subclassing of the parent StorageCapacity 
(iirc) class.  If we revert StorageShare back to (something like) an SRM 
Space, then a StorageShareCapacity can have different attributes to a 
Storage<VOView>Capacity, whilst both being a similar kind of "thing" (both 
are subclasses of StorageCapacity).

[Queue continued discussion on whether StorageCapacity is a "thing" ;-]

Just my 2c worth.

Paul.