-
Notifications
You must be signed in to change notification settings - Fork 0
/
RemoteJobSubmissionAPI.html
630 lines (594 loc) · 28 KB
/
RemoteJobSubmissionAPI.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Remote Job Submission API</title>
<link rel="stylesheet" href="_static/bootstrap-sphinx.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<link rel="stylesheet" type="text/css" href="_static/custom.css" />
<script type="text/javascript" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></script>
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/underscore.js"></script>
<script type="text/javascript" src="_static/doctools.js"></script>
<script async="async" type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Sample Logs" href="SampleLogsDev.html" />
<link rel="prev" title="Python vs C++ Algorithms" href="PythonVSCppAlgorithms.html" />
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-59110517-1', 'auto');
ga('send', 'pageview');
</script>
</head><body>
<div id="navbar" class="navbar navbar-default ">
<div class="container">
<div class="navbar-header">
<!-- .btn-navbar is used as the toggle for collapsed navbar content -->
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".nav-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="http://www.mantidproject.org"><img src="_static/Mantid_Logo_Transparent.png">
</a>
<span class="navbar-text navbar-version pull-left"><b>master</b></span>
</div>
<div class="collapse navbar-collapse nav-collapse">
<ul class="nav navbar-nav">
<li class="divider-vertical"></li>
<li><a href="index.html">Home</a></li>
<li><a href="http://download.mantidproject.org">Download</a></li>
<li><a href="http://www.mantidproject.org">Wiki</a></li>
<li><a href="http://docs.mantidproject.org">User Documentation</a></li>
<li><a href="http://www.mantidproject.org/Contact">Contact Us</a></li>
</ul>
<form class="navbar-form navbar-right" action="search.html" method="get">
<div class="form-group">
<input type="text" name="q" class="form-control" placeholder="Search" />
</div>
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
</div>
<div class="container">
<div class="row">
<div class="body col-md-12 content" role="main">
<div class="section" id="remote-job-submission-api">
<span id="remotejobsubmissionapi"></span><h1>Remote Job Submission API<a class="headerlink" href="#remote-job-submission-api" title="Permalink to this headline">¶</a></h1>
<div class="contents local topic" id="contents">
<ul class="simple">
<li><a class="reference internal" href="#basic-requirements-for-api-implementations" id="id3">Basic Requirements For API Implementations</a></li>
<li><a class="reference internal" href="#versioning" id="id4">Versioning</a></li>
<li><a class="reference internal" href="#authentication" id="id5">Authentication</a></li>
<li><a class="reference internal" href="#transactions" id="id6">Transactions</a></li>
<li><a class="reference internal" href="#a-note-about-file-uploads" id="id7">A Note About File Uploads</a></li>
<li><a class="reference internal" href="#api-v1-url-s" id="id8">API v1 URL’s</a><ul>
<li><a class="reference internal" href="#information" id="id9">Information</a></li>
<li><a class="reference internal" href="#id1" id="id10">Authentication</a></li>
<li><a class="reference internal" href="#id2" id="id11">Transactions</a></li>
<li><a class="reference internal" href="#file-transfer" id="id12">File Transfer</a></li>
<li><a class="reference internal" href="#file-listing" id="id13">File Listing</a></li>
<li><a class="reference internal" href="#job-submission" id="id14">Job Submission</a></li>
<li><a class="reference internal" href="#job-query" id="id15">Job Query</a></li>
<li><a class="reference internal" href="#job-abort" id="id16">Job Abort</a></li>
</ul>
</li>
<li><a class="reference internal" href="#api-v1-extensions" id="id17">API v1 Extensions</a><ul>
<li><a class="reference internal" href="#job-dates" id="id18">JOB_DATES</a></li>
<li><a class="reference internal" href="#auth-user-name" id="id19">AUTH_USER_NAME</a></li>
</ul>
</li>
</ul>
</div>
<p>This document describes the web service API that the Mantid Framework uses to submit algorithms to remote compute
resources. The API is designed to be flexible enough that it can be implemented for just about any compute resource at
nearly any facility. This document should hopefully contain enough detail for programmers & sysadmins at other
facilities to implement the API and allow Mantid users to submit jobs to compute resources at those other facilities.</p>
<p>A ‘compute resource’ may be any computer capable of running the Mantid framework. This could range from a single large
server, to some sort of Beowulf cluster to machines with specialized hardware such as GPU’s or Intel MIC’s. The idea is
that the ‘compute resource’ will be used to execute tasks that are impractical to run on the user’s local workstation.</p>
<p>The reference implementation is the Fermi cluster at the Oak Ridge Spallation Neutron Source (fermi.ornl.gov). Specific
details of the implementation on Fermi are used as examples throughout this document.</p>
<div class="section" id="basic-requirements-for-api-implementations">
<h2><a class="toc-backref" href="#id3">Basic Requirements For API Implementations</a><a class="headerlink" href="#basic-requirements-for-api-implementations" title="Permalink to this headline">¶</a></h2>
<p>The Mantid framework has certain expectations for the API and it’s the responsibility of API implementations to meet
these expectations:</p>
<ol class="arabic simple">
<li>The API provides a mechanism for executing python scripts in an environment that includes the Mantid framework. (ie:
one where “from mantid.simpleapi import *” works) (Note: exactly *how* this happens is purposely left up to the
implementor.)</li>
<li>Scripts are executed in a batch environment - interactive scripts are not supported and scripts must be able to run
without input from the user.</li>
<li>No mechanism for passing command line parameters to the python scripts is provided. Things like experiment and run
numbers must be hard-coded into the script. (We consider this acceptable because we expect a new script to be
auto-generated by MantidPlot for each job.)</li>
<li>Scripts can write output to what is the current working directory when the script starts. These output files will be
available for download back to MantidPlot (or wherever) once the script finishes.</li>
<li>Files that were uploaded prior to running the script will be available from the script’s working directory.</li>
<li>Authentication is used to prevent individual users from interfering with others’ jobs (or even reading their files)</li>
<li>Data from the various API calls is returned in two ways: the standard HTTP status codes (200, 404, 500, etc…) and
JSON text in the body. (Note: There’s no HTML markup in the output.) In the case of error status codes, the JSON
output will contain a field called ‘error_msg’ who’s value is a string describing the error.</li>
<li>Clients should assume that all parts of the URL - including query parameters - are case sensitive. However, servers
don’t *have* to accept URL’s with improper case, but may if it makes the code simpler.</li>
</ol>
</div>
<div class="section" id="versioning">
<h2><a class="toc-backref" href="#id4">Versioning</a><a class="headerlink" href="#versioning" title="Permalink to this headline">¶</a></h2>
<p>A quick Google search shows that versioning web API’s is tricky. The technique employed here will be to use a major
version plus optional extensions.</p>
<p>Between major versions there are no guarantees of backwards or forwards compatibility. Changing the major version is
essentially starting over from scratch with a clean slate. The major version starts at 1 and will hopefully never
change.</p>
<p>Backwards-compatible changes are handled by means of optional extensions.</p>
<p>A server must implement all of the functions defined in the base level of the version and a client may assume those
functions exist. A server is NOT required to implement the extensions (they’re optional) and a client may query the
server to discover which extensions are implemented. (Note that what the server returns is really just a name. It’s up
to the client and server implementers to agree on exactly what that name means and then document it - presumably here in
this API doc.)</p>
<p>Backwards-incompatible changes to the API are not allowed. That includes the URL itself, the GET or POST variables it
expects and the JSON that it outputs. If changes are needed, they can be handled through the extension mechanism. For
example, more GET or POST variables could be accepted by the server, so long as they are not required. An extension
should be created (and documented here) so that a client may query the server about whether it supports the new
variables.</p>
<p>Old GET or POST variables cannot be deleted however. This would break clients that expect to use them. If there’s a case
where old varibles no longer make sense, then a completely new URL should be created (and again, documented as an
extension).</p>
<p>Similar rules apply to the JSON data returned by the API. Extra fields can be added to the JSON returned by a URL, but
original fields may not be removed.</p>
<p>It’s worth noting that it is possible for extensions to be mutually exclusive.</p>
</div>
<div class="section" id="authentication">
<h2><a class="toc-backref" href="#id5">Authentication</a><a class="headerlink" href="#authentication" title="Permalink to this headline">¶</a></h2>
<p>The initial API uses HTTP Basic-Auth name/password combo for authentication. (Other methods may be added via API
extensions as described above.) Upon successful authentication, a session cookie is created. All other URL’s require
this session cookie.</p>
<p>Because the Basic-Auth scheme does not encrypt the password when it is sent to the server, the use of the HTTPS protocol
is <strong>STRONGLY</strong> encouraged.</p>
<p>Note that HTTP Basic-Auth is simply the mechanism for passing a username/password combo to the web service. Exactly how
the web service uses that combo to authenticate (and authorize) a user is not specified by the API. Individual
implementations are free to do what they like. (For example, the implementation on Fermi checks the username & password
against an LDAP server.)</p>
</div>
<div class="section" id="transactions">
<h2><a class="toc-backref" href="#id6">Transactions</a><a class="headerlink" href="#transactions" title="Permalink to this headline">¶</a></h2>
<p>The API details below mention starting & stopping transactions. It should be noted that in this context, the word
transaction doesn’t really have anything to do with databases. In this context, transactions are a mechanism for the web
service to associate files with specific jobs. Multiple jobs may be submitted under a given transaction.</p>
<p>Note that the API doesn’t specify how this association occurs. That is a detail left up to the individual
implementation. However, remember the points in the Basic Requirements section above about scripts reading from and
writing to their current working directory while not allowing other users to see or modify their files. That implies
that each job will store files in its own directory and will execute scripts from that directory. (This is, in fact, how
the implementation on Fermi works.)</p>
<p>A user must start a transaction after authenticating, but before transferring files or submitting job scripts. When the
user’s job (or jobs) has finished and the user no longer needs the files associated with the transaction, he or she
should end the transaction. This will allow the web service to delete the files and recover the disk space.</p>
</div>
<div class="section" id="a-note-about-file-uploads">
<h2><a class="toc-backref" href="#id7">A Note About File Uploads</a><a class="headerlink" href="#a-note-about-file-uploads" title="Permalink to this headline">¶</a></h2>
<p>It is generally assumed that the input files for the submitted python scripts are already available on the compute
resource (presumably via some kind of network filesystem). Thus, although the API allows for file uploads, this is
really intended for relatively small support files that a particular script might need. The HTTP protocol really isn’t
intended or suitable for transferring the sort of multi-gigabyte files that are likely to be the inputs for these python
scripts.</p>
</div>
<div class="section" id="api-v1-url-s">
<h2><a class="toc-backref" href="#id8">API v1 URL’s</a><a class="headerlink" href="#api-v1-url-s" title="Permalink to this headline">¶</a></h2>
<p>General notes:</p>
<ul class="simple">
<li>All URL’s expect GET requests unless otherwise noted.</li>
<li>The session cookie returned by the authentication URL is required by all other URL’s (except for the info URL)</li>
<li>Success is indicated by an HTTP status code in the 200 range. (Typically, 200, but in some cases 201.) Errors are
indicated with error codes in the 400 and 500 range.</li>
<li>In the case of errors, the JSON output will include a field named “Err_Msg” whose value is a text string describing
the particular error.</li>
</ul>
<div class="section" id="information">
<h3><a class="toc-backref" href="#id9">Information</a><a class="headerlink" href="#information" title="Permalink to this headline">¶</a></h3>
<table border="1" class="docutils">
<colgroup>
<col width="27%" />
<col width="73%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Description</td>
<td>Returns information about the server including the API version and supported
extensions.</td>
</tr>
<tr class="row-even"><td>URL</td>
<td><base_url>/info</td>
</tr>
<tr class="row-odd"><td>Query Parameters</td>
<td>None</td>
</tr>
<tr class="row-even"><td>JSON Output</td>
<td>API_Version : <integer> API_Extensions : [<extension_1>, <extensions_2>, …. ]
Implementation_Specific_Post_Variables : [ <variable_1>, <variable_2>, …. ]</td>
</tr>
<tr class="row-odd"><td>Notes</td>
<td>May be called without first authenticating. The
‘Implementation_Specific_Submit_Variables’ field lists the particular POST
variables that this implementation requires when submitting a job. See the
‘Job Submission <#Job_Submission>`__ URL.</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="id1">
<h3><a class="toc-backref" href="#id10">Authentication</a><a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h3>
<table border="1" class="docutils">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Description</td>
<td>Authenticate to the web service.</td>
</tr>
<tr class="row-even"><td>URL</td>
<td><base_url>/authenticate</td>
</tr>
<tr class="row-odd"><td>Query Parameters</td>
<td>None</td>
</tr>
<tr class="row-even"><td>JSON Output</td>
<td>None</td>
</tr>
<tr class="row-odd"><td>Notes</td>
<td>Username and password are passed in using HTTP Basic
Authentication Returns a session cookie which must be
passed to the other URL’s</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="id2">
<h3><a class="toc-backref" href="#id11">Transactions</a><a class="headerlink" href="#id2" title="Permalink to this headline">¶</a></h3>
<p>This URL has two forms: one to start a new transaction and the other to end an existing transaction.</p>
<table border="1" class="docutils">
<colgroup>
<col width="42%" />
<col width="58%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Description</td>
<td>Start a new transaction</td>
</tr>
<tr class="row-even"><td>URL</td>
<td><base_url>/transaction</td>
</tr>
<tr class="row-odd"><td>Query Parameters</td>
<td>Action=Start</td>
</tr>
<tr class="row-even"><td>JSON Output</td>
<td>TransID : <string></td>
</tr>
<tr class="row-odd"><td>Notes</td>
<td> </td>
</tr>
</tbody>
</table>
<table border="1" class="docutils">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Description</td>
<td>End an existing transaction</td>
</tr>
<tr class="row-even"><td>URL</td>
<td><base_url>/transaction</td>
</tr>
<tr class="row-odd"><td>Query Parameters</td>
<td>Action=Stop TransID=<transaction_id></td>
</tr>
<tr class="row-even"><td>JSON Output</td>
<td>None</td>
</tr>
<tr class="row-odd"><td>Notes</td>
<td>Once a transaction is stopped, any files associated with
it will no longer be available for download and the
server is free to delete those files.</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="file-transfer">
<h3><a class="toc-backref" href="#id12">File Transfer</a><a class="headerlink" href="#file-transfer" title="Permalink to this headline">¶</a></h3>
<table border="1" class="docutils">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Description</td>
<td>Transfer a file from the server back to the client</td>
</tr>
<tr class="row-even"><td>URL</td>
<td><base_url>/download</td>
</tr>
<tr class="row-odd"><td>Query Parameters</td>
<td>TransID=<transaction ID> File=<filename></td>
</tr>
<tr class="row-even"><td>JSON Output</td>
<td> </td>
</tr>
<tr class="row-odd"><td>Notes</td>
<td><filename> does not include any path information. The
actual directory where the file is stored is chosen by
the web service and hidden from the user</td>
</tr>
</tbody>
</table>
<table border="1" class="docutils">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Description</td>
<td>Transfer one or more files from the client up to the
server</td>
</tr>
<tr class="row-even"><td>URL</td>
<td><base_url>/upload</td>
</tr>
<tr class="row-odd"><td>Query Parameters</td>
<td>None</td>
</tr>
<tr class="row-even"><td>JSON Output</td>
<td>None</td>
</tr>
<tr class="row-odd"><td>Notes</td>
<td>This is a POST method Multiple files may be submitted
with one call
File(s) are submitted as
multipart form data (ie: “Content-Type:
multipart/form-data” header)
File names should not include
any directory or path information. (Exactly where the
file is stored is left to the web service to determine.)
The transaction ID must also be
specified as form data with a field name of “TransID”
On success, returns a “201 - Created” status code</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="file-listing">
<h3><a class="toc-backref" href="#id13">File Listing</a><a class="headerlink" href="#file-listing" title="Permalink to this headline">¶</a></h3>
<table border="1" class="docutils">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Description</td>
<td>Return a listing of files associated with the specified
transaction</td>
</tr>
<tr class="row-even"><td>URL</td>
<td><base_url>/files</td>
</tr>
<tr class="row-odd"><td>Query Parameters</td>
<td>TransID=<transaction ID></td>
</tr>
<tr class="row-even"><td>JSON Output</td>
<td>Files : [ <file_1>, <file_2>, … <file_n> ]</td>
</tr>
<tr class="row-odd"><td>Notes</td>
<td>No guarantees are made about the order files are listed</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="job-submission">
<h3><a class="toc-backref" href="#id14">Job Submission</a><a class="headerlink" href="#job-submission" title="Permalink to this headline">¶</a></h3>
<table border="1" class="docutils">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Description</td>
<td>Submit a python script for execution on the compute
resource</td>
</tr>
<tr class="row-even"><td>URL</td>
<td><base_url>/submit</td>
</tr>
<tr class="row-odd"><td>Query Parameters</td>
<td>None</td>
</tr>
<tr class="row-even"><td>Mandatory POST Variables</td>
<td>TransID : <trans_id>
ScriptName : <name_of_python_script>
<name_of_python_script> : <python code></td>
</tr>
<tr class="row-odd"><td>Optional POST Variables</td>
<td>JobName : <name></td>
</tr>
<tr class="row-even"><td>Implementation Specific POST Variables</td>
<td>NumNodes : <number_of_nodes>
CoresPerNode: <cores_per_node></td>
</tr>
<tr class="row-odd"><td>JSON Output</td>
<td>JobID : <job_id></td>
</tr>
<tr class="row-even"><td>Notes</td>
<td>This is a POST method
Request is submitted as multipart form data (ie:
“Content-Type: multipart/form-data” header)
POST variables listed above are individual form data
fields
The content of the “ScriptName” field specifies the name
of the python script. There must be another field with
this name that actually contains the python code. This
allows the web service to keep track of multiple scripts
associated with the same transaction.
The JobName variable allows the user to specify a name
for a job. The name is included in the output of queries.
(Presumably, the user will pick a name that’s more
descriptive and easier to remember than the automatically
assigned job ID.)
The Implementation Specific Post Variables are - like the
name says - specific to a particular implementation. They
may not be applicable to all implementations and it’s
valid for an implementation to ignore those that aren’t.
Which variables are required by a specific implementation
are listed in the <a class="reference external" href="#Information">Information</a> URL.
(The two specified above are used by the Fermi
implementation, and would probably be valid for all
compute clusters.)</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="job-query">
<h3><a class="toc-backref" href="#id15">Job Query</a><a class="headerlink" href="#job-query" title="Permalink to this headline">¶</a></h3>
<p>This URL has two forms: one to query a specific job and one to query all of a user’s jobs.</p>
<table border="1" class="docutils">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Description</td>
<td>Query all jobs submitted by the user</td>
</tr>
<tr class="row-even"><td>URL</td>
<td><base_url>/query</td>
</tr>
<tr class="row-odd"><td>Query Parameters</td>
<td>None</td>
</tr>
<tr class="row-even"><td>JSON Output</td>
<td><job_id> : <job_description_object>
<job_id> : <job_description_object>
<job_id> : <job_description_object>
etc…</td>
</tr>
<tr class="row-odd"><td>Notes</td>
<td>See below for a description of the job_description_object
The length of time the compute resource will ‘remember’
jobs is up to the implementer, but several days should be
considered an absolute minimum. (A user should be able to
submit a job on Friday and still be able to query it on
Monday morning.)</td>
</tr>
</tbody>
</table>
<table border="1" class="docutils">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Description</td>
<td>Query one specific job submitted by the user</td>
</tr>
<tr class="row-even"><td>URL</td>
<td><base_url>/query</td>
</tr>
<tr class="row-odd"><td>Query Parameters</td>
<td>JobID : <job_id></td>
</tr>
<tr class="row-even"><td>JSON Output</td>
<td><job_id> : <job_description_object></td>
</tr>
<tr class="row-odd"><td>Notes</td>
<td>See below for a description of the job_description_object
The length of time the compute resource will ‘remember’
jobs is up to the implementer, but several days should be
considered an absolute minimum. (A user should be able to
submit a job on Friday and still be able to query it on
Monday morning.)</td>
</tr>
</tbody>
</table>
<p>The job description object is a JSON object who’s fields contain specific information about the job. The fields are:</p>
<ul class="simple">
<li>TransID - The transaction ID the job is associated with</li>
<li>JobName - The name that was given to the submit API</li>
<li>ScriptName - The name of the python script that was executed</li>
<li>JobStatus - The execution status of the job. Will be one of: RUNNING, QUEUED, COMPLETED, REMOVED, DEFERRED, IDLE or
UNKNOWN</li>
</ul>
</div>
<div class="section" id="job-abort">
<h3><a class="toc-backref" href="#id16">Job Abort</a><a class="headerlink" href="#job-abort" title="Permalink to this headline">¶</a></h3>
<table border="1" class="docutils">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Description</td>
<td>Abort a previously submitted job. Jobs that are queued
will be dequeued. Jobs that are running will be stopped
immediately. Jobs that have already completed will simply
be ignored.</td>
</tr>
<tr class="row-even"><td>URL</td>
<td><base_url>/abort</td>
</tr>
<tr class="row-odd"><td>Query Parameters</td>
<td>JobID : <job_id></td>
</tr>
<tr class="row-even"><td>JSON Output</td>
<td>None</td>
</tr>
<tr class="row-odd"><td>Notes</td>
<td>Returns a 400 error code if the job ID does not exist.</td>
</tr>
</tbody>
</table>
</div>
</div>
<div class="section" id="api-v1-extensions">
<h2><a class="toc-backref" href="#id17">API v1 Extensions</a><a class="headerlink" href="#api-v1-extensions" title="Permalink to this headline">¶</a></h2>
<div class="section" id="job-dates">
<h3><a class="toc-backref" href="#id18">JOB_DATES</a><a class="headerlink" href="#job-dates" title="Permalink to this headline">¶</a></h3>
<p>The JOB_DATES extension adds three fields to the job_description_object that is returned by queries. The fields are
“SubmitDate”, “StartDate” & “CompletionDate” which represent the dates (including time) that the job was first
submitted, when it started executing and when it stopped (either because it finished or because it was interrupted for
some reason). The values are ISO8601 strings suitable for importing into a Mantid DateAndTime object.</p>
</div>
<div class="section" id="auth-user-name">
<h3><a class="toc-backref" href="#id19">AUTH_USER_NAME</a><a class="headerlink" href="#auth-user-name" title="Permalink to this headline">¶</a></h3>
<p>The AUTH_USER_NAME extension adds a single field the the JSON text returned by the ‘info’ URL. The field name is
‘Authenticated_As’ and its value is either the name of the user that’s been authenticated, or empty if no authentication
has taken place yet.</p>
</div>
</div>
</div>
</div>
</div>
</div>
<footer class="footer">
<div class="container">
<ul class="nav navbar-nav" style=" float: right;">
<li>
<a href="PythonVSCppAlgorithms.html" title="Previous Chapter: Python vs C++ Algorithms"><span class="glyphicon glyphicon-chevron-left visible-sm"></span><span class="hidden-sm hidden-tablet">« Python vs C++...</span>
</a>
</li>
<li>
<a href="SampleLogsDev.html" title="Next Chapter: Sample Logs"><span class="glyphicon glyphicon-chevron-right visible-sm"></span><span class="hidden-sm hidden-tablet">Sample Logs »</span>
</a>
</li>
<li><a href="#">Back to top</a></li>
</ul>
<p>
</p>
</div>
</footer>
</body>
</html>