[ur-wg] Meeting Notes

[Rosario Michael Piro]

Matthew Ford wrote:
> Quoting "Donal K. Fellows" <donal.k.fellows at manchester.ac.uk>:
> 
>> Future version to extend to more complex things than batch system job
>> accounting.
> 
> 
> But I think think we have this now!  Maybe I'm reading too much into the 
> term
> "extend".  It's much more a change of method and clarification that I would
> like to see.  As you move through-out the document it becomes increasingly
> generalised.  By section ten, I believe the current specs clear 
> intention is to
> be able to account much more than a batch job.  However it's not with out
> problem.
>

It is true that the general structure of the UR and most of it's 
elements allow for a more general case, but I believe that that would 
not be enough. Storage accounting, for example, would most probably 
require additional elements such as FileIdentity/FileName. Other 
elements (Disk) are already in place. I think the usage-related elements 
(network, disk, memory, etc.) already provide most of what would be 
needed, but the identity-related elements are still too batch 
job-specific. We should concentrate concentrate generalization efforts 
first on these.

> Some thoughts and quotes:
> 
> - Job Level Accounting from the Original Spec is supposed to work at the 
> batch
> job level.  It is restricted form of the usage of the base properties of
> section 3 or later the common properties of section 10.
> 
>  From Sec.4: "Job level accounting reports accounting data at the job 
> level. PBS
> and LoadLeveller.  This type of usage record MAY contain any of the base
> properties. This type of usage record MUST contain at least one of the
> following properties:o LocalJobId o GlobalJobId"
> 
> - Aggregate Accounting is specifically allowed, and integral to the 
> current doc.

I still believe that what is missing is an explicit differentiation 
between aggregate records and non-aggregate records (this might also be 
a simple attribute type="aggregate" to the UsageRecord element!?). An 
aggregate record should at least clearly state that it is aggregate and 
this statement should be unambiguosly defined, such that each 
UR-"consumer" (whether a user, or a RUS) can undoubtfully distinguish 
between these records). An aggregate record might (or should) also allow 
multiple JobIdentity elements to be present.

> 
>  From Sec.5: "Aggregate accounting reports the accounting data in aggregate
> (summarized form). Aggregate accounting MAY contain any of base properties
> listed in this document,"
> 
>  From Introduction: "Aggregation: Most sites have indicated that job-level
> aggregation is sufficient for their current needs. Where sites aggregate or
> decompose to other levels of usage tracking, provisions are
> available within the schema to accommodate."
> 
>  From Sec.3: "Base Properties: The following is a list of base 
> properties that
> define common usage record requirements for both job level and aggregate
> properties."
> 
> - The Global definitions in sections 7,8 and 9 clearly intend to setup a 
> generic
> framework in which most types of usage can can be accounted.
>  + Sec.7 sets-up Global Elements to allow substitution for inclusion 
> into other
> schemas.
>  + Sec.8. sets-up Global attributes sets up generic attributes which 
> maintain
> meaning independent of context. i.e, forcing common usage of units.
>  + Sec.9. specifically sets-up a *generic* usage record
> 
>  From Sec.7 "The global definitions are those that may be used 
> compliantly with
> this specification as root elements for an XML document or which may be 
> used as
> extension points within or included within other XML Schema definitions."
> 
>  From Sec.8 "Global attributes, and attribute groups, are attributes 
> that are
> common to many of the element definitions contained in this 
> specification. A
> global definition of these maintains standard semantic meaning within each
> context that they are used."
> 
>  From Sec.9 "UsageRecordType Complex Type: This complex type definition
> establishes the structure of the *generic* usage record."
> 
> - Section 10, Usage Record Common Properties is an obivious attempt to
> generalise the base proprieties of section 3.  The problem is that not 
> all the
> base properties of section three are appropriate as Common Properties for a
> *generic* record.  Further as the bulk of section 3 is seemingly based 
> on batch
> level reporting, the scope of the section is serverely limited.
> 
>  From Sec.10 "10. Usage Record Common Properties: the complete 
> specifications for
> each element that MAY appear in the *generic* usage record are presented 
> below."
> 
>>
>> Stick with using email for resolving issues; not worth changing
>> technologies half way through.
>>
>> Short-term Timeline:
>>   Mailing list discussions to close: 30 June
>>   Consensus: 15 July
>>   Revised document: 15 August
>>   Submit to editor: 1 September
>>
>> Three-way joint meeting: OGSA RUS UR
>>
>> Call for use cases and reference implementations
>>
>> Telecons
>> ========
>> Keep going. Biweekly. One hour. 1300 UTC. First on 25 May.
>> ----------------------------------
>>
>> Donal Fellows.
>>
>>
> 


-- 
-------------------------------------
    Rosario Piro (piro at to.infn.it)
     http://www.to.infn.it/~piro/
-------------------------------------
Istituto Nazionale di Fisica Nucleare
Sezione di Torino
-------------------------------------
National Insitute for Nuclear Physics
Section of Turin, Italy
-------------------------------------