[RUS-WG] Ideas for the RUS specification

[Gilbert Netzer]

Hi everybody,

first of I would like to thank Joshua Green from EPCC for his analysis
and comments on the current RUS specification draft (see
http://www.ogf.org/pipermail/rus-wg/attachments/20081128/36ebeb84/attachment-0001.pdf,
also sent to this list in November 2008). Such input is vital for the
working group to make any progess!

After reading the comments and reflecting on the current state of the
RUS IDL draft and the problems and concerns that have been raised
during various meetings and email conversations on this list I suspect
that at least part of the trouble is caused by the RUS specification
actually trying to define a interface for three different use-cases:

- The record producer (e.g. resource, Grid-site) that wants to publish
  usage information to a consumer (e.g. accounting system, logging
  system).

- The Grid user (or a manager) that wants to browse usage information
  to check her own usage (or site usage or anything else of interest).

- The Grid manager (or VO/RC administrator) that needs to rectify
  incorrect usage information (e.g. change misconfigured site name in
  the usage records).

All these three usage scenarios are important for RUS implementations
and have different implications depending on the intended use of the
deployed RUS. The interesting observation about these three scenarios
is that they seem to be almost orthogonal to each other:

The producer typically would use the listMandatoryUsageRecordElements
and the insert operations to publish new records, the "end"-user
(which may be a computer system, agent etc.) typically would use the
extract operation to get published usage information while the
"admin"-user would use the modify and delete operations to remove or
change wrong usage records.

All these functions seem important in a real RUS (or accounting
system) deployment but the requirements on each of the outlined
scenarios varies considerably and any implementation therefore has to
make independent tradeoffs on each of the three scenarios and a
one-size-fits-all solution for each of these use-cases is likely to be a
bad choice for some aspects of the system. However the current
specification is formulated such that each implementation that would
like to claim conformance is forced to provide standard interfaces for
all three use-cases. This leads to the problem that a implementation
would for instance have great use of the publishing part but the other
two interfaces fit badly for the intended use (as mentioned in Joshuas
comments) which may lead implementors to either seek other
(non-conformant) solutions or simply implement only part of the
specification (i.e. extract, modify and delete could always return
permission denied errors). This would lead to a situation where lots
of different RUS conformant implementations coexist that cannot
interoperate because they implement different parts of the
specification, something that really is not intended.

A solution to this problem would be to split the specification into
several parts that each serve a distinct use-case (e.g. information
publishing) and allow implementors to choose which of the parts they
need. 

In the RUS case the common denominator and least controversial part
seems to be the publishing of usage record information. Since this
functionality on its own is valuable for existing accounting systems
and has actual use-cases (e.g. EGEE/APEL or SweGrid/SGAS) I would
suggest to start by factoring out this part from the compound
specification. To avoid confusion I would suggest to name this
specification in a different way (e.g. Usage Record Publishing
Interface or Resource Metering Service).

Other specifications could be concerned with information extraction
and administration and could be produced by this or other working
groups or even standardization bodies.

My big question is if this idea is interesting for current (or
planned) RUS implementations?

Best Regards
Gilbert Netzer
PDC/KTH