[DRMAA-WG] IDL issues

[Peter Tröger]

Hi,

> The bigger ones are likely caused by my limited understanding of the
> background which led to the design, so please bear with me - I don't
> want to reopen any discussions which have been closed for good...

I like your attitude ;-) ...

>    - the enum ResourceLimitType does not seem to be used anywhere

It defines the valid keys for JobTemplate::resourceLimits, so it does 
not show up in the signatures.

>    - the enum JobTemplatePlaceholder does not seem to be used anywhere

It defines the valid macros usable in job template attributes, see 
Section 4.4. in Draft 6.

>    - I think the following is asymmetric.  There is likely a reason,
> but I am not sure I understand it:
>
>      - job     session: create (name, contact), open (name), close
> (session), destroy (name)
>      - reserv. session: create (name, contact), open (name), close
> (session), destroy (name)
>      - monit.  session: create (      contact),              close (session)
>
>      From the above, it seems like create/close are pairs?  I would
> naively expect the following
>      pairs: open/close and create/destroy, as usual - what is the rationale?

I don't get your point. Creation returns a new persistent XXXsession 
instance. Open allows you to re-access the persistent existing session. 
Close is for cleanup after both create and open. Destroy throws away the 
persistent information, and therefore does not demand an open session 
instance.

>      Why is the Monitoring session handled differently, i.e. has no
> name/open/destroy?

Monitoring session have no persistency, so they need no name for 
opening, and no destruction.

>    - jobInfo.exitStatus is a long.  Shouldn't that be an int?  Or is
> that an IDL artifact?

Yes. There are no INTs in IDL.

>    - inErrorState: this is not explained - what does it mean?  Am I
> getting reservation in an error state?  What for?  also, reservations
> don't seem to have state, really?  (BTW: I did not check if all
> attributes are explained, just stumbled over this one.  This should be
> checked).

Oops, we removed that one, but I forgot to fix the IDL too. Thanks.

>    - JobWaitStarted/Terminated: The function returns always a Job
> object, in order to allow chaining,
>      e.g. job.wait(JobStatus.RUNNING).hold(). The session-level functions
>
>      I find that strange and inconsistent - chaining is not supported
> elsewhere AFAICS, why here?
>      What is the advantage over 'job.wait(JobStatus.RUNNING);
> job.hold();'? this has exactly the same race conditions...

Chaining was raised as important thing only for the wait functions. I am 
too lazy to search the minutes for this, but it is handy in OO 
languages. We didn't spend deeper thoughts on supporting this elsewhere. 
Proposals welcome.

>
>    - StringList getJobSessions();
>      StringList getReservationSessions();
>
>      All getXYZ methods in the API return XYZ, apart from these two -
> which return the name of XYZ.
>      IMHO, they should either return XYZ, or should be called
>
>      StringList listJobSessions();
>      StringList listReservationSessions();

Sounds reasonable to me, I put that on the open issues list for the group.

>    - sessionManager.drmaaVersion: this seems to return the
> implementation version, not the
>      DRMAA spec version (i.e. 2.0).  I think this is useless without
> also reporting the
>      drmaaName, i.e. the implementation name.  Otherwise the user may
> report to you that
>      she is using version 4.5, but what implementation?? ;-)

You get the DRMS type, this is your DRMAA implementation. I propose that 
there will be no two DRMAA implementations for the same DRM system in 
the same language.

>    - what is the use of the sessionManager interface?  It cannot be
> created/destroyed, so is likely a singleton?
>      This however is not explicit in the spec.  A sessionManager does
> not seem to have state (apart from the new
>      addition of a monitoring callback), but a stateless singleton is
> rather useless?  All methods can easily be
>      provided as free functions - is a language binding allowed to do that?

Yes, it's a singleton. Yes, you can do free functions in the language 
binding. IDL does not support that.

>    - "sessionName: is supposed to be unique - if a session with that
> name was created before, an exception is thrown."
>      Hmm, 'created before'?  ever?  by anybody?  Or only for this
> session manager instance?  Or this DRM system?  etc etc.

Argh, we missed that one. I put it on the list of open issues. Since 
sessions are expected to be submission-host specific, this should be 
also the answer here.

Thanks for your help !

Peter.