[OGSA-BES-WG] BES Last Call

[Christopher Smith]

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 at jp.fujitsu.com> wrote:

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