[ogsa-hpcp-wg] [OGSA-BES-WG] BES Last Call

[Andreas Savva]

Chris,

[Some comments inline.]

Christopher Smith wrote:
> On 06/2/07 19:41, "Andreas Savva" <andreas.savva at 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