[drmaa-wg] Another Argument for a DRMAA_ERRNO_UNSUPPORTED_ATTRIBUTE Error Code

[Peter Troeger]

>>I think you have correctly identified that the error codes
>>specified in the C-lang spec for drmaa_set_attribute() do
>>not adequately describe the situation when an attribute is
>>not supported.
>>
>>Should it ?
>>I did not locate any text in the spec which indicates that
>>it is an error to specify an unsupported (or unrecognized)
>>attribute.
>>On the other hand, I also did not locate any text which
>>indicates that unsupported attributes will be ignored.
>>
> 
> I think you just discovered a new tracker item. :)  It should be
> specified one way or the other.  Otherwise, DRMAA applications will not
> be portable across implementations.

The current IDL spec seems to make a clear description:

"In the job template there is a distinction between mandatory and 
optional attributes. A language binding implementation MUST provide 
implementations for all DRMAA attributes, both required and optional. 
The setter and getter implementations for optional attributes MUST throw
UnsupportedAttributeException in languages which support exceptions.  In 
languages which do not support exceptions, the optional attribute 
setters and getters MUST return some form of error.  The service 
provider implementation SHOULD then override the setters and getters for
supported optional attributes with methods that operate normally."

and:

"5.6.26 UnsupportedAttributeException: The given job template attribute 
is not supported by the current DRMAA implementation."

In sum, it is specified to be an error if you use an unsupported 
attribute. If we have a new C-binding document, based on the IDL-spec, 
then everything should be fine !?

>>>(Caching the supported argument list doesn't help if
>>>the list can change during the lifetime of the DRMAA
>>>application, as is the case with SGE.)
> ... 
> You bring up an interesting point.  Should a job template be aware of
> such changes in the DRMS?  Right now, ours are.  I can easily see the
> point that a mutable job template is a moving target and could drive a
> developer nuts.  On the other hand, a job template may be very long
> lived.  We completely take away the control from the admin if we allow a
> job template to hold onto an environment that should no longer exist.
> 
> Honestly, what makes sense to me at this moment is to specify the list
> of supported optional attributes as immutable for a given
> implementation.  In cases like ours, where our support of an attribute
> is dependent on the configuration of the DRMS, we should return
> something like DRMAA_ERRNO_DENIED_BY_DRM on job submission.  Thoughts?

 From the viewpoint of an application developer, I have a very bad 
feeling with this. I would never expect a change of the list of 
supported optional attributes, especially not during the runtime of my 
application. If the admin wants to do some reconfiguration, she is 
reponsible of considering still running applications. If you really 
think that this a useful feature at all, I would support the 
DRMAA_ERRNO_DENIED_BY_DRM suggestion. However, the spec really needs to 
make this explicit.

Peter.