Hi Laura, hi everybody. Laura F McGinnis wrote:
GGF18 in Washington, DC is only 2 weeks away. I hope you are planning to come. We have a lot on the schedule, and I'm hoping to make good progress on our documents.
This time I'll be able to attend the meeting.
... The second session we're scheduled to host is planned to be a joint session with other resource-related working and research groups. I will extend invitations to these groups shortly, so please let me know which ones you feel should be included. The list I have so far is: OGSA Resource Selection Services (OGSA-RSS-WG) OGSA Resource Usage Service (RUS-WG) Production Grid Services (PGS-RG) Standards development organizations Collaboration on networked Resources Management Working Group (SCRM-WG)
I think we should at least have a joint meeting with the RUS-WG, since the RUS directly depends on the UR. But extending the meeting also to other WGs interested in the resource tracking would be a good thing. Cheers, Rosario. PS: I attached our original comments to the UR spec. draft, since there are currently problems with getting them from the public comments webpage or the mail archive. -- ------------------------------------- Rosario Piro (piro@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 ------------------------------------- Comments on draft-Rec-UR-Usage Record Format Recommendation Usage Record-WG 2.2.4, (Time stamps), page 5, states that the time zone should be enumerated or UTC should be assumed, while in section 6.2.5.1 (discrete time values) All points in time MUST indicate a specific time zone. 3.8 (Charge) there is an unspecified reference (XXYYZ) in the second paragraph. The third paragraph states that the charge must be of type integer while its definition on page 26 includes "xsd:float", which is more appropriate 3.9 (Status) states that the property MUST be of type integer and it MUST also support values like "aborted", ecc. In section 10.6, status is correctly defined as an extension of "xsd:token". 3.11 (cpuDuration) substitute "Description MAY be specified" instead of " Duration MAY be specified". 3.14 and 3.15: MachineName and Host may not be sufficient where, for example, there is more than one cluster at a site. We propose to have an additional element "SiteName". Furthermore in some grids the grid resource ID is different from Host, MachineName or SiteName (for example, for LCG/EGEE, computing element IDs such as "t2-ce-01.lnl.infn.it:2119/jobmanager-lcglsf-cms" are used as resource IDs and there may be several (logical) computing elements on a single cluster). Thus there should be an additional element, "ResourceID". 3.18 (ProjectName) Since a single VO may be involved in several projects and several VOs may be involved in the same project (thus having only the ProjectName is not sufficient), the usage record should contain an element indicating the "UserVO" Additionally, the role (such as VO admin, student ...) of a user might influence issues like charging or quota enforcement. It would therefore be good to have an additional element "UserRole" (might also be a part of the element UserVO that we proposed above). 3.19 (Network) is of type postiveInteger, not simply integer; see section 11.1 which is correct 3.20 (Disk) Disk is of type postiveInteger, not simply integer; see section 11.2 which is correct 3.21 (Memory) Memory is of type postiveInteger, not simply integer; see section 11.3 which is correct 3.22 (Swap) Swap is of type postiveInteger, not simply integer; see section 11.4 which is correct 6.22 First two lines are duplicated 8.5 and 8.6 Please explain why the attribute MUST not attempt to differentiate between requested and utilized quantities within a single record since such a differentiation might be useful. Alternatively an additional UR element "UsageStatus" (or something similar) might be used to distinguish between URs for "requested" and "utilized" resources. 8.6 (Type) The first paragraph is confusing since it first states that the attribute "identifies the type of resource" and then the "type of measurement...regardless of the resource" 9.1.1 (Content Model) does not seem to be up to date (for example, ProcessID is missing and UserIDentity is not differentiated in LocalUserID and GlobalUsername, etc.) 10.1.2 cites createTime while the schema cites createDate 10.3 The GlobalUsername is missing in the Schema at the end of the section. For Storage URs, an element FileIdentity should be added 10.8 (CpuDuration) The CPU time alone cannot be a measure of consumed resources without having more information about the processor(s)/processing power (10 sec on a Commodore 64 are not equal to 10 sec on a Pentium IV) We hence propose adding an element ProcessingPower (or something equivalent) allowing for different units such as SpecInt or SpecFloat for normalization purposes. 10.9 The reference in the first paragraph should be 10.6 10.10.1 start time instead of end time. Rosario Piro Albert Werbrouck Andrea Guarise Giuseppe Patania INFN Torino, Italy.