Hi Chris, I would suggest as a way forward to divide and conquer. Can we agree first on the exact text for the definitions of the faults, staying on a single (perhaps very conservative) reading. And then choose which one to apply to the various cases? I asked the initial question because I could not understand why the case of giving an OS value from the JSDL-defined enumeration (well-defined presumably) would fall in the same category as that of specifying a fractional or negative value for CPUCount. Andreas Christopher Smith wrote:
On the fault issue ... fair enough ... making the fault a MUST when the OS is not recognized (same text for CPU architecture) is ok with me.
-- Chris
On 08/2/07 22:13, "Andreas Savva" <andreas.savva@jp.fujitsu.com> wrote:
Chris,
[Some comments inline.]
Christopher Smith wrote:
On 06/2/07 19:41, "Andreas Savva" <andreas.savva@jp.fujitsu.com> wrote:
Chris,
Chris Smith wrote:
UnsupportedFeatureFault indicates that a particular element or attribute contained within the JSDL document is either not supported, or (for extension content) not supported or recognized.
InvalidRequestMessageFault indicates that the value of some element is invalid input. For example, if TotalCPUCount in JSDL was given as -10. This is nice text and I hope it is included in the BES spec. "...not recognized" is not correct.
The recognized part referred to extension content where the element might not be known to the consuming system (as opposed to being known, but unsupported). I have no problems dropping it.
I think simplifying and tightening the fault definitions in BES would be a good idea.
Also given the above, HPC Profile sections 3.9 and 3.10 specify the wrong value for the returned fault. For example in 3.9 it says
If the consuming system does not provide the requested operating system, or if the JSDL special token ³other² is used as the content of the jsdl:OperatingSystemName sub-element, and if the consuming system does not understand the provided extension content, then the consuming system MAY return the BES InvalidRequestMessageFault to the requester. It should be UnsupportedFeatureFault. (And why is the fault returned a MAY and not a MUST for the profile?)
Ahh ... it is InvalidRequestMessage ... that's because the element (OperatingSystemName) is recognized and supported by the system, but the "value" of OperatingSystemName is not recognized. I know this seems in conflict with the statements about UnsupportedFeatureFault above, but in this case, the extension elements are the "value" of the OperatingSystemName element (if that makes sense).
The reason for the MAY is in the phrase "If the consuming system does not provide the requested operating system....". Some systems may choose to accept the JSDL as is, and might just have an activity whose resource requirements can never be satisfied (unless an operating system of that type is configured in the system and made available to the BES). This would be the case for my BES implementation on top of LSF, which allows one to specify resources that may never be satisfied.
I agree with Karl's comments in a separate email that these distinctions seem too subtle and overload the meaning of the faults. The HPC Profile (being a profile) should be the same or more (and definitely not less) restrictive and precise than the BES specification on returned faults.
Btw, on a different topic, HPC Profile section 3.11 TotalCPUCount says "non-negative integer" which includes the value of 0. I guess this type should be "positive integer".
-- Andreas Savva Fujitsu Laboratories Ltd