SourceForge : Post

Project: Editor Discussion > REC:Usage Record Format Recs > Proposal for additional UR elements > List of Posts

Forum Topic - Proposal for additional UR elements: (4 Items)

View: as

None

01/10/2006 10:29 AM

post4810

Proposal for additional UR elements

1) Concerning Sections 3.14 and 3.15 of the specifications: 

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" (see also the proposed name change from MachineName to SiteName by Dave Kant, 
keeping both elements instead of changing names might allow to include more detailed information in the UR, specifying 
both the cluster name as MachineName and the site ID as 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".

2) Concerning Section 3.18 (ProjectName) of the UR specification: Since a single Virtual Organization (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" (see also the equivalent proposal by
 Dave Kant).

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).


Rosario Piro
Albert Werbrouck
Andrea Guarise
Giuseppe Patania

INFN Torino, Italy.

None

01/10/2006 10:36 AM

post4811

further elemetns ...

1) For storage URs, an element FileIdentity might be added.

2) Concerning Section 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.

3) Concerning Sections 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.


Rosario Piro 
Albert Werbrouck 
Andrea Guarise 
Giuseppe Patania 
 
INFN Torino, Italy.

To contact us, write to:

{piro,werbrouck,guarise,patania}@to.infn.it

Laura McGinnis

08/31/2006 5:23 PM

post5647

Re: further elemetns ...

> 1) For storage URs, an element FileIdentity might be added.

For V1 implementations, either use the disk description metaproperty or include filename as an extension.
 
> 2) Concerning Section 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.

CpuDuration is the correct field for measuring resource utilization. Comparisons between resource capabilities are 
beyond the scope of this document, but should be addressed by in the implementation context as agreed upon by the 
resource providers.

This is a complicated topic, esp. due to the heterogeneous nature of grid computing. Since it is resource-dependent, not
 job-dependent, it is out of scope.

> 3) Concerning Sections 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.

Differentiation between requested and utilized resources should be handled as separate usage record instantiations.

Laura McGinnis

08/31/2006 5:15 PM

post5646

Re: Proposal for additional UR elements

> 1) Concerning Sections 3.14 and 3.15 of the specifications: 
> 
> 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
> " (see also the proposed name change from MachineName to SiteName by Dave Kant
> , keeping both elements instead of changing names might allow to include more 
> detailed information in the UR, specifying both the cluster name as 
> MachineName and the site ID as 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".

MachineName is sufficiently unrestricted in V1 of the recommendation to allow inclusion of site information where needed
. V2 may consider additional structure re: resource and entity identification.

> 2) Concerning Section 3.18 (ProjectName) of the UR specification: Since a 
> single Virtual Organization (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" (see also the equivalent proposal by Dave Kant).
> 
> 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).

UseVO and UserRole are out of scope for V1. Data may be included in description fields for user identity data.

Return