[OGSA-BES-WG] BES Last Call
Christopher Smith
csmith at platform.com
Fri Feb 9 11:34:15 CST 2007
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".
More information about the ogsa-bes-wg
mailing list