Minutes for the joint RUS-WG and UR-WG meeting
OGF20 Manchester, Thursday May 10, 2007, 9:00-10:30am, Exchange 4/5


Comment on mandatory UsageRecord elements:
Currently only RecordIdentity and Status are declared mandatory. It would be
interesting to declare profiles for certain job types (e.g. computational,
storage, network) that contain more mandatory elements. 


Aggregation of UsageRecords (slide 11):

For aggregation of UsageRecord data in the RUS, the RUS could define its own
format since it is a report and this would not needed to be fed back into the
UR-WG.
 
In the context of the RUS, another use-case would be the publishing of
aggregated information into a RUS. This would be the input side, and
should be covered by the UR specification. The same format could then
also be used for the output. 
This aggregation could also be carried out directly at the resource.

The original purpose of the UR-WG was to standardize data that would
be coming directly out of the resource, aggregation seems the natural way
forward.

Aggregated data is also often exchanged between sites, projects or in a
VO. 

There are different types of aggregation, some of which keep the detail
information (more like a sequence of records), some of which only have
summary information. The UR-WG is starting to gather requirements on the
UR v2 specification, aggregation is part of it, so are other types of
usage for non-compute resources. 

The approach seems to be like an "ocean-boiling" exercise. It would be
beneficial to identify the new requirements, define the needed elements
and add them to the current specification. This would prevent a reset of
the clock for the v2 specification. 
Also the specification already has some elements for storage usage and
it contains some extension hooks that could be utilized. The discussion
about other resources is currently vague, it needs further refinement.

The term v2 is just a guideline, the new spec will aim at compatibility
if possible. Fitting storage usage into the current schema is relatively
easy, however network is much more complicated to retrofit.

There already exists a proposed aggregate UsageRecord specification. We
could use this as a basis and keep things in separate documents.
This would allow the two strings to run in parallel without blocking each
other.

Another proposal is to include information about VO membership in the
UsageRecord. This is important for VO accounting. 
However to keep the changes simple only the most pressing needs should be
addresses. All the changes should be driven from the user-community. Also
an experience document needs to be written for the v1 specification, which
can help in finding the requirements from the user community.
Furthermore a proposal for an aggregation format already exists.


Adding new elements to the UR specification (slide 13):

Adding elements to the UsageRecord specification can really make the format
messy, it is better to have a distinct format and borrow or import elements
from the UsageRecord specification.

When specifying the aggregate usage record format as a separate format, a
basic proposal is already available. On a technical plane, it should be
assigned to the UR-WG. 

It is a new format and if it is only interesting for returning and exchanging
data it should go into the RUS-WG.

However the format can be used outside the context of RUS and it is not really
clear that it could not be used outside the RUS, so it is more natural to have 
it in the UR-WG.

Is would be best to separate the schemata into two name-spaces, one for the
aggregate structure and one for the elements. This would allow easy reusing
of the elements.

A question is where this aggregated record would be stored. 

In the simplest case a sensor would create URs, insert them into a RUS, the
RUS would aggregate and queries could be answered with AURs. 
In the collaboration case, RUS A would insert AURs into RUS B from where it
would be queried as AURs.

For the RUS it would be good to have two different operations, one to provide
detailed data, the other to provide aggregated data. 
To query data, full XPath expressions are used which are independent of UR.

To conclude the discussion, a separate AUR specification is favored.


Other proposals for UR v2 (slide 14):

Add a VOName property:
The project name could possibly be used, but it is better to have an explicit
property. LCG also has a number of VOs that span multiple grids, so federation
of grids poses an interesting use-case for exchange of such accounting data.
Usage of the extension hooks might create problems because different people
could use different names for the same thing or even worse the same name
for different things.


Add a FQAN property:
The FQAN seems to be structured, that should be explicitly expressed in the
schema.

The FQAN is like a DN, from the schema it can be treated like a string and
pattern matching can be used on it. There is no need to parse its internal
structure.

Other types of URs:
The UR-WG needs more outreach to find the requirements for this usage types.
A connection to the enterprise side of the Grid would be of advantage. 

It would also be good to give feedback to the reference model WG.

One approach to different UR types would be to have a common base and
extensions for each type. 

The original idea of the UR-WG was to use the resource type field to 
distinguish the type and then fill in the appropriate fields.



Proposal for Workshop at OGF22:

At OGF22 a workshop for gathering experience with the UR specification is 
planned, this workshop could also be used for requirements gathering by the 
RUS-WG.

A joint RUS+UR-WG session could be used as a follow-up on the workshop to 
define the path forward.