Standards » Management Area » UR WG

h1. StAR updates

h2. Comments to StAR during the public comment period

---

h3. SITE field required by EGI and WLCG

The key site identifier in the EGI and WLCG e-infrastructures is the SiteName as defined by GOCDB. This should be added to the StAR definition. 

While the storage element fqdn could possibly be resolved to a site name by software using the accounting data, the definition should be under the control of the site when publishing, not subject to later action by other parties.

h3. StorageResourceCapacityAllocated proprty to be added

In the StorageUsageBlock the property StorageResourceCapacityAllocated should added alongside StorageResourceCapacityUsed and StorageLogicalCapacityUsed. 

By analogy with wallclock time signifying a cpu resource being blocked from other use and so a reasonable thing to be accounted and charged, storage space allocated is unavailable to other users on many systems. 

It should be an optional property to be used by those who wish to account and charge for space allocated instead of, or as well as, space used.

An example use case would be a site who allocates whole disk servers or whole instances of storage systems to VOs, not sites who merely give VOs quotas in a bigger storage system.

This comment is on behalf of EGI and WLCG.

h3. Comment originally posted by hartdavidl 2012-02-22

In addition to the fields listed, for accounting purposes, the record may want to permit the inclusion of a "charge" that is a function of the capacity used, in the same way that HPC job charges are often calculated as core-hours or node-hours modified by a queue or priority factor. In storage accounting, the bytes stored could be modified based on the StorageShare (e.g., slower disk vs. faster disk), StorageClass (e.g. pinned, replicated classes cost more), or MediaType (e.g., disk costs more than tape).

Second, the record does not permit accounting for storage "activity", i.e. the bytes and/or files read and/or written by respective users, if this is of interest (or available). If such values are supported, the forward-looking ValidDuration field may need to be redefined or replaced as a retrospective TimeDuration field, since the recorded reads/writes would apply in the TimeDuration leading up to the MeasureTime.

---

h2. Suggested new fields

h3. Site

This property describes the site at which the resource is located. This property should contain a descriptive name of the group of resources containing the storage system which is accounted for in the record. The Site field value should be constructed in such a way that it is unique within the accounting domain where the record is used.

* The Site field type MUST be a string.

Example

<pre>

<sr:Site>ACME-University</sr:Site>

</pre>

h3. ResourceCapacityAllocated

This property describes the number of bytes allocated on the storage system or storage share where appropriate. Depending on implementation this property may be equal to ResourceCapacityUsed (see section 2.4.19), however this property should only take into account space allocated to the entity described in the record, not resources used for redundancy in RAID setups, tape holes, or similar.

* The ResourceCapacityAllocated field type MUST be a nonnegative integer.

Example

<pre>

<sr:ResourceCapacityAllocated>14624</sr:ResourceCapacityAllocated>

</pre>

h3. TimeDuration

Was decided in February to use StartTime and EndTime instead of MeasureTime and {Time,Valid}Duration.

h3. StartTime

This property describes a timestamp indicating the time at which the measured resource consumption started. Together with EndTime (see section 2.4.18) this defines a period over which the resource has been consumed.

* The StartTime field MUST be present in the record.

* The StartTime field type MUST be an ISO timestamp.

* The time zone may be specified as Z (UTC) or (+|-)hh:mm. Time zones that aren't specified are considered undetermined.

Example

<pre>

<sr:StartTime>2010-10-11T09:31:40Z</sr:StartTime>

</pre>

Implementation note: The period defined by EndTime-StartTime could define the period over which the storage system measured a storage integral. In a simpler case, EndTime is the current time of mesasurment and StartTime the preceding measurement.

h3. EndTime

This property describes a timestamp indicating the time at which the measured resource consumption ended. Together with StartTime (see section 2.4.17) this defines a period over which the resource has been consumed.

* The EndTime field MUST be present in the record.

* The EndTime field type MUST be an ISO timestamp.

* The time zone may be specified as Z (UTC) or (+|-)hh:mm. Time zones that aren't specified are considered undetermined.

Example

<pre>

<sr:EndTime>2010-10-12T09:29:42Z</sr:EndTime>

</pre>

Implementation note: See note for section 2.4.17