January 2009 - drmaa-wg - lists.ogf.org

Conference call -Feb 3rd - 17:00 UTC
by Peter Tröger 05 Feb '09

05 Feb '09

Dear all, the bi-weekly DRMAA call is scheduled on Feb 3rd, 2009. The meeting starts at 17:00 UTC == 18:00 CET (Berlin/Poland time) == 9:00 PST (Vancouver time) Phone conference line sponsored by Sun: Phone number (toll-free from US): +001-866-545-5227 Access code: 5988285 Preliminary meeting agenda: 1. Meeting secretary for this meeting? 2. Voting about "UNDETERMINED" job state - keep it as own job state ? - Means permanent or temporary problem ? 3. Voting about separate "TERMINATED" vs. "FAILED" state - Semantics - Resulting new job state transitions 4. Further DRMAA2 discussion Best regards, Peter.

4 5

Another proposal
by Daniel Templeton 04 Feb '09

04 Feb '09

A customer just pointed out the awkwardness of the drmaa_control() operation. As a rule, I don't like operations whose behavior is controlled by a flag. It's generally easier to learn and easier to read is the name of the operation is descriptive of exactly what it does. What would people think of replacing the drmaa_control() operation with drmaa_suspend_job(), drmaa_release_job(), drmaa_hold_job(), drmaa_resume_job(), and drmaa_terminate_job() operations. I don't see the downside, myself. Daniel

3 3

Conf call minutes - Jan 20th 2009
by Daniel Gruber 31 Jan '09

31 Jan '09

Attendees: Peter Troeger Dan Templeton Hrabri Rajic Daniel Gruber 1. Meeting secretary for this meeting? Daniel Gruber 2. Next IDL language binding ? Python binding was finished within 3 months -> efficient Do we want to do it again for Java / C binding? -> low priority -> DRMAA2 is currently more important 3. DRMAA2 schedule (requested by Steven) -> doable within 6 months -> some time for approval after that -> there are two OGF meetings in this time (26th and 27th) -> earlier agreement: fixing everything we identified 4. DRMAA2 feature discussion Do we need "System Hold"/ "User Hold" differentiation? -> idea: reason as exception? -> agreed on that it is not really necessary Undetermined - is it a valid job state? -> Yes! Undetermined = Error -> Condor: it is permanent some time -> Need to clarify if this means "don't try again" or "try it again" Distinction between state "failed" and "terminated" -> "Failed" := user can fix it (through changes on job template for example) -> "Terminated" := error the user can't fix TODO later: DRMAA wait state will be discussed other time Why should we support extensible state? -> basically for reporting -> problem: difficult to implement in C Solution for more fine grained states (and "User/System Hold" problem) -> add another output parameter (a DRM specific string) or constants for job state -> hence "Hold" could be one state -> fine grained states could additionally retrieved via such DRM specific string or constant -> proposal: one string and a reference to a generic object/struct -> will appear in draft later on! Problem with state transition in Condor from "Suspend" to "Queued Active"! -> should be supported (at least 3 people agreed) 5. Continue with email threads for discussion. 6. Next meeting: 3rd February 2009

4 3

DRMAA v2
by Daniel Templeton 30 Jan '09

30 Jan '09

A few proposals for the meeting today: PT12: < A language binding SHOULD specify numeric values for all DRMAA error constants. --- > Such a language binding SHOULD specify numeric values for all DRMAA error constants. PT13: I definitely agree that PartialTimestamp is a boondoggle. I'm not sure I agree with using ISO8601, though, mostly because it presupposes a date/time *string*. In a high order language, I want to be able to use the native date/time object. How about specifying that a language should use a date/time object or primitive is it has one, and an ISO8601 string if it doesn't? PT20: I think we can handle the resource request pretty easily, and I think we need it. We just need to add a resourceRequest attribute of type Dictionary and treat any such resource request as a hard request. Alternatively, we could have a hardResourceRequest and a softResourceRequest. The former is simpler, but the later saves us from talking about this again for DRMAAv3. :) Thinking about whether a resource request should be an optional attribute makes created in me a doubt about the value of the UnsupportedAttributeException. Should it be possible to have the implementation just ignore unsupported optional attributes? It would certainly be easier than repeatedly attempting to submit until all the offending attributes are removed from the template. Maybe it would help to have the exception detail *all* unsupported attributes at once. Just thinking out loud here... Daniel

2 1

about DRMAA perl bindings
by 云何 21 Jan '09

21 Jan '09

Hi, I use perl module Schedule::DRMAAc to operate Sun grid-engine in perl scripts. I can use this module to submit a job, but how can I use it to list all the job in a queue, just like the function of command "qstat -f" ? Thank you. Best Jarod ___________________________________________________________ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/

2 1

DRMAA2: Job State Model Discussion
by Peter Tröger 19 Jan '09

19 Jan '09

Dear all, this discussion thread is intended to clarify the new job state model in DRMAA2. DRMAA1 allows the following job states: UNDETERMINED QUEUED_ACTIVE SYSTEM_ON_HOLD USER_ON_HOLD USER_SYSTEM_ON_HOLD RUNNING SYSTEM_SUSPENDED USER_SUSPENDED USER_SYSTEM_SUSPENDED DONE FAILED The following questions are already identified, please provide your expertise: Which states need to be removed / added from the viewpoint of PBS, LSF, Condor, SGE, Unicore, GridWay, OGSA-BES and SAGA ? Which of the job states were never realized in DRMAA implementations ? Can we remove them ? Which of the states are too generic ? How do we resolve this ? Which of the existing state transitions are a problem ? Missing ones ? Do we want an extensible job state model as in OGSA-BES ? If yes, how to realize ? More questions are welcome, but first try to answer the given ones. Thanks, Peter.

2 1

Looking for DRMAA for LSF feedback
by Piotr Domagalski 19 Jan '09

19 Jan '09

Dear DRMAA users, It has been almost a year since we've been involved in work on DRMAA for Platform LSF. What we are looking for now, is your feedback. Based on this, we are going to decide how would our further commitment to the project look like. Please provide answers to the following questions and feel free to give your additional comments. - Would you like DRMAA for LSF to come bundled with LSF distribution? Would that convince you to use it in your application? - Would integrated bindings for other languages (Python, Ruby, Java?) convince you to use DRMAA? - DRMAA2 is an ongoing work on the new version of the standard. Are you looking forward to seeing DRMAA2 implementation for Platform LSF? - Would you be interested in a lightweight Web Service remote submission mechanism based on DRMAA? - Are you interested in a DRMAA-like API for Advance Reservation in LSF? So, if you are already using DRMAA in applications at your company or planning to do so, please let us know. Your feedback is very valuable to us! Best regards, -- Piotr Domagalski FedStage Systems Ltd.

1 0

Python binding reached OGF document status
by Peter Tröger 13 Jan '09

13 Jan '09

Dear all, the Python language binding was officially published as GFD.143: http://www.ogf.org/gf/docs/?final Congratulations and thanks to all contributors. Best regards, Peter.

1 0

Conference call - Jan 20nd - 17:00 UTC
by Peter Tröger 13 Jan '09

13 Jan '09

Dear all, the bi-weekly DRMAA call is scheduled on Jan 20nd, 2009. The meeting starts at 17:00 UTC == 18:00 CET (Berlin/Poland time) == 9:00 PST (Vancouver time) Phone conference line sponsored by Sun: Phone number (toll-free from US): +001-866-545-5227 Access code: 5988285 Preliminary meeting agenda: 1. Meeting secretary for this meeting? 2. Next IDL language binding ? 3. DRMAA2 schedule (requested by Steven) 4. DRMAA2 feature discussion Best regards, Peter.

1 0

Re: [DRMAA-WG] Questions regarding DRMAA: getting running Job status
by Daniel Templeton 13 Jan '09

13 Jan '09

Jack, There is, unfortunately, no way to do that today. It is, however, something we are considering for the DRMAA v2 spec currently underway. For now, you have to get that information from qstat. qstat has a -xml option that should be easier to parse. At http://passau.dev.java.net/ you will find some JAXB bindings for the qstat -xml output, but they're probably out of date by now. Daniel Jie Zhang wrote: > Hi Dan, > My name is Jack Zhang, a EE student in Johns Hopkins University. > I'm currently working on implementing a grid engine and creating a > DRMAA job manager using JAVA for the center of imaging science. > your blog and your comments has helped me a lot in the past, and sorry > for sending an email directly to you. but i want to ask you some > questions that i couldn't find information on. > > i want to get the status of a job with DRMAA, not only the what > getJobPrgramStatus returns, but also more information such as the > resources using, submission time and etc. but i have not find a method > that could do that except creating a jobinfo object using wait(). > which could only be done when the job is completed. if i want to get > those information while the job is running, is there a way to do it? > > thank you, and look foward to your replies > -- > Jie (Jack) Zhang > > Johns Hopkins University, Undergrad > Department of Electrical and Computer Engineering > Department of Economics > Engineers Without Borders, JHU Chapter > Tel: 443-388-0216 > Email: jzhang41(a)jhu.edu <mailto:jzhang41@jhu.edu>

1 0