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

[Roger Brobst]

========
Regarding specifying unsupported attributes ...

The C-lang and current IDL spec have provisions for
handling both required and optional DRMAA attributes.

The 3rd type of attribute, DRMS-specific, was intentionally
not discussed in the C-lang binding spec because they do not
impact the API.  From DRMAA's perspective they are simply
attributes which are not named with the DRMAA_ prefix.

Since the C-lang binding has the caller provide the
attribute name and value, there is no linkage problem
if the underlying implementation does not understand
the DRMS-specific attribute.

How does the current IDL spec support DRMS-specific attributes,
keeping in mind that the end customer should be able to choose
the DRMAA implementation leveraged by the ISV software ?
Explicit getters/setters for each attribute would seem
to be problematic (certainly from a linkage perspective).

========
Regarding the set of supported attributes changing ...

I think the C-lang binding spec should document that the value
output by drmaa_get_attribute_names (and 
drmaa_get_vector_attribute_names) should be valid for the 
lifetime of the drmaa session.


-Roger


In a previous e-mail, Peter Troeger wrote:
> >>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.