Etienne Urbah on 2010-04-01

• Propose requirement with title  'The Job Description document MUST reference all grid entities in conformance to the GLUE specification'

Amsterdam meeting on 2010-04-28

• Source = GIN
• Spreadsheet ID = 100
• Agreed YES

Etienne Urbah on 2010-12-08

• Figure 1 of the 'Job Submission Description Language (JSDL) Specification, Version 1.0' clearly shows that, in order to work correctly, a 'Superscheduler, or Broker, or …' has to match client requirements expressed in the JSDL document to information provided by a Grid Information System.
  Therefore, it is essential that client requirements on entities described by GLUE use only GLUE classes and attributes.
  For XML purposes, I propose to use the 'glue' namespace specified at http://schemas.ggf.org/glue/2008/05/spec_2.0_d42_r01

• Searching for JSDL elements clearly incompatible with GLUE 2.0, I have found following ones (but careful study by other persons could perhaps find other ones) :

• JSDL 'ProcessorArchitectureEnumeration' specified in JSDL section 5.2.1 and used by the 'CPUArchitectureName' element specified in JSDL section 6.4.15 :
  The corresponding GLUE 2.0 enumeration is 'Platform_t' specified in GLUE 2.0 appendix B.26.
  While some JSDL values (such as 'powerpc' and 'sparc') match GLUE 2.0 values, some other JSDL values (such as 'x86_64', 'x86_32' and 'ia64') do NOT match GLUE 2.0 values (which are respectively 'amd64', 'i386' and 'itanium').
  Therefore, I propose to deprecate JSDL 'ProcessorArchitectureEnumeration' and replace it with GLUE 2.0 'Platform_t' enumeration (for XML, inside the above described 'glue' namespace).

• JSDL 'OperatingSystemTypeEnumeration' specified in JSDL section 5.2.3 and used by the 'OperatingSystemName' element specified in JSDL section 6.4.12 :
  The corresponding GLUE 2.0 enumerations are 'OSFamily_t' specified in GLUE 2.0 appendix B.23 and 'OSName_t' specified in GLUE 2.0 appendix B.24.
  GLUE 2.0 permits the client to specify the desired OS either through a vague requirement ('OSFamily' attribute) or through a precise requirement ('OSName' attribute).
  Therefore, I propose to deprecate JSDL 'OperatingSystemTypeEnumeration' and replace it with the GLUE 2.0 'OSFamily_t' and 'OSName_t' enumerations (for XML, inside the above described 'glue' namespace).

• Practical usage of the 2 previous proposals permitting backward compatibility should be easily achieved using the JSDL 'other' value as described in JSDL section 4.3 'Semantics of the JSDL “other” Value'.

PGI telcon on 2010-12-09

• Mark: What does 'values do not match' mean ?
• Etienne: This means that the values describe the same architecture with different names.
• Oxana: This means that the enumerations are not the same (bottom line).
• Andrew: I agree to align to GLUE2, to use space additions for enumerations when 2 groups call them differently.

• Morris: We need a general strategy to integrate GLUE2 details inside JSDL.
• Agreement on 'Example of GLUE2 extension and integration inside JSDL':
  • We integrate GLUE2 elements in some parts of the JSDL job description
  • JSDL should be further used and not replaced, but augmented with GLUE2.

• Morris: What is your feeling of re-using the GLUE2 parts that are compatible ?
• Etienne: Some GLUE2 attributes do NOT conflict with JSDL, and can be directly integrated inside JSDL.
  As first candidates for integration inside JSDL, I propose the GLUE2 attributes of the 'ExecutionEnvironment' class (Chapter 6.6 of GLUE 2.0).
• Morris: We have to prepare a discussion on these candidates for the next telephone conference.
• Etienne: I will contribute to this preparation.

• Morris: Are the attributes of the 'ComputingService' class of GLUE2 also good candidates for integration inside JSDL ?
• Etienne: These attributes are only numbers of jobs, therefore I think that they are NOT good candidates.  I prefer to focus on 'ExecutionEnvironment' attributes, which describe hardware.

Etienne Urbah afterthoughts on 2010-12-09

• In fact, many attributes of the 'ComputingService' class of GLUE2 are good candidates for integration inside JSDL indeed.
• Clients may for example issue requirements on computing services having :
  • given values for 'Capability',
  • a given 'Type' or 'QualityLevel',
  • low values for 'WaitingJobs', 'SuspendedJobs', ...
• Anyway, I will focus first on 'ExecutionEnvironment' attributes, and then on attributes of other classes.