
The concall is scheduled for tomorrow (Thursday), June 8. Call-in details are online at http://www.psc.edu/~lfm/PSC/Grid/UR-WG/ConCallInfo.html. We will discuss the draft that Donal posted to the mailing list last week. It's in the UR-WG email archives at http://www-unix.gridforum.org/mail_archive/ur-wg/2006/05/msg00082.html. Thx LM ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Laura F. McGinnis, Project Coordinator Data & Information Resource Services Pittsburgh Supercomputing Center email: lfm@psc.edu 300 South Craig St, #313 phone: 412-268-5642 Pittsburgh, PA 15213 fax: 412-268-5832 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

In today's call, there was a little bit of confusion over the topic of identity and compound usage records in Donal's strawman. After an off-line discussion with Matt Ford, I think I can make his question clearer with a more concrete example. In the strawman, we would be allowed to construct a document containing a compound usage record which itself contains a sequence of compound usage records, each of which comprises two atomic usage records, containing e.g. (1) some usage information about a compute job, and (2) usage information about an associated network reservation. As I understand it, Matt's question pertained not to the identity of the agent producing the record, nor to the identity of the ultimate end-user, but rather to how to identify the intermediate compound record as being about compute+network usage. I think what this comes down to is that the atomic usage records might need to be more strongly typed. Stephen
-----Original Message----- From: owner-ur-wg@ggf.org [mailto:owner-ur-wg@ggf.org] On Behalf Of Laura F McGinnis Sent: 08 June 2006 03:33 To: ur-wg@ggf.org Subject: [ur-wg] Concall tomorrow
The concall is scheduled for tomorrow (Thursday), June 8. Call-in details are online at http://www.psc.edu/~lfm/PSC/Grid/UR-WG/ConCallInfo.html.
We will discuss the draft that Donal posted to the mailing list last week. It's in the UR-WG email archives at http://www-unix.gridforum.org/mail_archive/ur-wg/2006/05/msg00 082.html.
Thx LM
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++ Laura F. McGinnis, Project Coordinator Data & Information Resource Services Pittsburgh Supercomputing Center email: lfm@psc.edu 300 South Craig St, #313 phone: 412-268-5642 Pittsburgh, PA 15213 fax: 412-268-5832 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++

Stephen M Pickles wrote:
In the strawman, we would be allowed to construct a document containing a compound usage record which itself contains a sequence of compound usage records, each of which comprises two atomic usage records, containing e.g. (1) some usage information about a compute job, and (2) usage information about an associated network reservation. As I understand it, Matt's question pertained not to the identity of the agent producing the record, nor to the identity of the ultimate end-user, but rather to how to identify the intermediate compound record as being about compute+network usage.
OK. I think I understand. That's something that the CompoundUR does not try to tackle at all. The CUR definition makes no assertions at all about the meaning of the compound; they're together because someone or something thinks they should be together. However, I believe it would be possible (maybe after a bit more schema hacking) to further subclass the CUR to get a kind of compound UR that defines what the compound means, which is not a problem at all from my perspective, or failing that, the extra meaning could be attached to the CUR through its extensibility support. I'm not stating which is preferred, and I can see reasons for doing things both ways. (Subclassing allows for better enforcement of any extra rules, extending is easier to make interoperable, even if not in a necessarily useful way.)
I think what this comes down to is that the atomic usage records might need to be more strongly typed.
More types of UsageRecord (e.g., SRMUsageRecord, NetworkLinkUR)? That's fine with me, except for the actual matter of really writing them. At that point, my laziness takes over. :-) Donal.

Hi All, I'd just like to summarize and comment on the changes between the existing UR schema and Donal's proposal - this may put the UR2.0 discussion into context. My previous email, http://www-unix.gridforum.org/mail_archive/ur-wg/2006/05/msg00058.html outlines what the current schema provides and what the spec aimed for. I think the framework for the construction a record remains essentially the same with some movement of elements and additional nice properties. Usage Record Type ------------------ UR-WG: <xsd:complexType name="UsageRecordType"> Donal: <xsd:complexType name="UsageRecord"> The UR-WG has a more complex structure than that of Donal's as for legacy reasons it defines a lot of fields for batch job accounting. By moving these out of this type definition and into a sub-class we hope to avoid problems of semantics and scope for these elements. The RecordStart and RecordEnd time elements Donal defines could have used the UR-WG StartTime,EndTime definitions but it will have left the semantics open. I'm not sure they should be mandatory though see final section. List/Compound Records ---------------- UR-WG: <xsd:element name="UsageRecords"> Donal: <xsd:element name="CompoundUsageRecords"> The only major difference I notice here is the ability to have list of lists in Donal's schema vs. a flat list of the UR-WG schema. Atomic/Job Records ------------------ UR-WG: <xsd:element name="JobUsageRecord"> Donal: <xsd:element name="AtomicActivityUsageRecord"> The UR-WG defined JobUsageRecord but as it inherited the UsageRecordType with all it's many elements it did not have any need to extend it in any way. Donal's AtomicActivityUsageRecord does move some of the elements out the super type but I think still leaves us with the same problem. AtomicActivity I feel is a generic label that could be applied to many things. By defining PeakNodes and AverageMemory aren't we still in our heads thinking about compute jobs? These labels could mean different things in different contexts. I could have used these in network context rather than a batch system (and we go back to the scoping and semantics comments). Further I could have an atomic activity in some sensor which the terms don't make sense. You don't have to use them, but you can't possible account for every scenario. I would prefer to see a BatchUsageRecord type etc. I still like something like my previous example: in this "jobusage" means "batch job usage". <UsageRecord> <Base Properties> <RecordId/> <Accounting Period/> </Base Properties> <Grid Job> <JobUsageRecords> <JobUsageRecord/> ... </JobUsageRecords> <DataRecord/> </Grid Job> </UsageRecord> UserIdentity/RecordIdentity/AccountingPeriod --------------------------------------------
From UR-WG section 3: -Record Identity uniquely defines a record in the usage record - it doesn't identify how or what generated the report. -UserId/GlobalUsername identify the user consuming the resource.
At present I generate a UsageRecord from a batch job not an accounting period. How do I fill in the mandatory RecordStartTime/EndTime in Donal's schema in such a case (it doesn't make sense to I only have the start-time and end-time of the job)? How far down this road should we go? It would be very handy for me to query a RUS service and get back a UR that contains the accounting period and summary info and the query that generated it and the list of resources used and and and!. Should this be part of the RUS spec though rather than UR....should they be more closely coupled? Matt.
participants (4)
-
Donal K. Fellows
-
Laura F McGinnis
-
Matt Ford
-
Stephen M Pickles