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

[Paul Millar]

Hi all,

So, I've been thinking about publishing storage related objects, particularly 
with the WLCG accounting use-cases.  One of the use-cases calls for 
associating each portion of a storage element to one or more VOs so that 
these can be used for per-VO accounting.

In Glue 2.0, this association most naturally follows from instantiating 
MappingPolicy objects that act as links between StorageShare objects and 
UserDomain objects.

An interesting issue is how to represent a single shared (i.e., multiple VOs 
may use) StorageShare.  This can be represented (equivalently) as either:
	a single MappingPolicy object pointing to multiple UserDomain policies
or
	multiple MappingPolicy objects, each pointing to the same
	StorageShare object.  Each MappingPolicy object points to a single
	UserDomain object, but each of these UserDomain objects is different.

(In fact, these two options are two extremes: one could publish a mixture of 
these)

Aside: do we *really* need this flexibility?  It seems to create unnecessary 
complication for the clients.  We can remove it by changing either the Share: 
MappingPolicy.ID multiplicity to "optional" (0..1) or (Mapping)Policy: 
UserDomain.ID multiplicity to "required" (1).  The former seems the better 
option (IMHO).

We identify which StorageShares are to be used for accounting by selecting 
only those StorageShares that are published with a SharingID attribute value 
of "dedicated".

The metric values to be used for storage accounting are the attached 
StorageShareCapacity objects.

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

The WLCG InstalledCapacity would then be:
	InstalledCapacity = TotalSize + UnavailableSize
	
Cheers,

Paul.