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

[Andreas Savva]

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

-- 
Andreas Savva
Fujitsu Laboratories Ltd