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
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="christian reissmann">
<meta name="GENERATOR" content="Mozilla/4.76C-CCK-MCD [en] (X11; U; SunOS 5.8 sun4u) [Netscape]">
</head>
<body>
<h3>
<b><font size=+2>Standard Compatibility Test</font></b></h3>
<p>
<br>
<br>
<p>Compatibility is an important aspect of the <a href="/project/gridengine/license.html">License</a>
under which Grid Engine source code is made available. In this context,
cross compatibility may have to be certified between a version of the Grid
Engine software which you have enhanced and a version declared as one of
Grid Engine's <font color="#990000">Reference Builds</font> from which
your modification deviates. Note, that over time there can be multiple
Reference Builds representing different stable software release levels.
You might intend to test compatibility with one or with multiple of those
Reference Builds. A list of the currently available Reference Builds with
all pertinent information can be found <a href="/project/gridengine/standards.html">here</a>.
<p>The following describes how to test compatibility between two builds.
You will need to create a <a href="../source/dist/dist.html">binary distribution
package</a> for both builds before you start with the compatibility
checking process. You will also have to make all preparations to be able
to run the Grid Engine <a href="../testsuite/testsuite.html">Testsuite</a>.
You will have to use the Testsuite level as defined in the <a href="/project/gridengine/standards.html">Reference
Build definition</a>.
<p>The compatibility test consist of a preparation step, a validation run
of the Standard Version and multiple compatibility checks. Your changed
version has to pass all tests without error and has to deliver the same
results as the validation run to be considered compatible.
<p>
<hr WIDTH="100%">
<br>Release Notes:
<p> <a href="#notes_5_3">Version 5.3</a>
<p>
<hr WIDTH="100%">
<h3>
Preparation:</h3>
<ul>
<li>
Set up a testsuite cluster with more than one host</li>
</ul>
<blockquote>The <a href="../testsuite/testsuite.html">Testsuite</a> documentation
is describing how this can be done. Use the <b><i>Reference Build</i></b>
to which you want to test compatibility and run:</blockquote>
<blockquote>
<blockquote><tt>expect check.exp install</tt></blockquote>
The testsuite will generate a default setup file "defaults.sav" in the
testsuite directory. After that the testsuite will start the vi command
in order that the user can edit the testsuite settings. You will be asked
on which hosts you want to install a testsuite cluster and you will have
to use at least 2 for the purpose of the compatibility test. Please enable
the error mails by providing your e-mail address when setting up the testsuite.
The testsuite will report errors by e-mail.</blockquote>
<h3>
Validation:</h3>
<ul>
<li>
Run testsuite on Reference Build</li>
<br>
<p>
<p>Run the testsuite with following command (<a href="#testsuite start output">Testsuite
start output</a>):
<br>
<ul><tt>expect check.exp all 2 category COMPATIBILITY</tt></ul>
<p><br>Do not remove the test results of the validation run. Every testsuite
run will manipulate the results directory, so copy your validation results
before running another test. You will need to compare your validation run
results with the subsequent compatibility runs. No errors must occur during
the validation run. If you encounter errors then this might be due to network
setup problems in your cluster or similar issues. Fix those first before
you proceed. Report your problem if it persists. You cannot test compatibility
with a validation run with errors.</ul>
<h3>
Check 1: Qmaster compatibility</h3>
<ul>(If you are absolutely sure that your modification did not change sge_qmaster
you may skip this step, but be aware that changes in some libraries, like
for instance the scheduler library, may also modify sge_qmaster. Carry
out the test if you are not 100% sure.)
<br>
<li>
Shutdown the system</li>
<br>
<p>
<p>Use the testsuite to shutdown the cluster:
<br>
<ul><tt>expect check.exp kill</tt></ul>
</ul>
<ul>
<li>
Exchange the sge_qmaster binary with the one from your modified build</li>
</ul>
<ul>
<li>
Run the testsuite again:</li>
<br>
<ul><tt>expect check.exp all 2 category COMPATIBILITY</tt></ul>
<li>
Compare results with validation run</li>
<br>
<ul> Stop if the results are not equal.</ul>
<li>
Shutdown the system</li>
<br>
<p>
<p>Use the testsuite to shutdown the cluster:
<br>
<ul><tt>expect check.exp kill</tt></ul>
<li>
Re-Exchange the sge_qmaster binary with the one from the Reference Build</li>
</ul>
<h3>
Check 2: Scheduler compatibility</h3>
<ul>(If you are absolutely sure that your modification did not change sge_schedd
you may skip this step, but be aware that changes in some libraries, like
for instance the GDI library, may also modify sge_schedd. Carry out the
test if you are not 100% sure.)</ul>
<ul>
<li>
Exchange the sge_schedd binary with the one from your modified build</li>
</ul>
<ul>
<li>
Run the testsuite again:</li>
<br>
<ul><tt>expect check.exp all 2 category COMPATIBILITY</tt></ul>
<li>
Compare results with validation run</li>
<br>
<ul>Stop if the results are not equal.</ul>
<li>
Shutdown the system</li>
<br>
<p>
<p>Use the testsuite to shutdown the cluster:
<br>
<ul><tt>expect check.exp kill</tt></ul>
<li>
Re-Exchange the sge_schedd binary with the one from the Reference Build</li>
</ul>
<h3>
Check 3: Commd compatibility</h3>
<blockquote>(If you are absolutely sure that your modification did not
change sge_commd you may skip this step, but be aware that changes in some
libraries, like for instance the zlib, may also modify the sge_commd. Carry
out the test if you are not 100% sure.)</blockquote>
<ul>
<li>
Exchange all sge_commd binaries with the ones from your modified build</li>
</ul>
<ul>
<li>
Run the testsuite again:</li>
<br>
<p>
<br>
<br>
<ul><tt>expect check.exp all 2 category COMPATIBILITY</tt></ul>
<li>
Compare results with validation run</li>
<ul>
<br>Stop if the results are not equal.</ul>
<li>
Shutdown the system</li>
<br>
<p>
<p>Use the testsuite to shutdown the cluster:
<br>
<ul><tt>expect check.exp kill</tt></ul>
<li>
Re-Exchange the sge_commd binaries with the ones from the Reference Build</li>
</ul>
<h3>
Check 4: Client compatibility</h3>
<blockquote>(If you are absolutely sure that your modification did not
change any Grid Engine client binary you may skip this step, but be aware
that changes in some libraries, like the GDI library, may also modify
the client binaries. Carry out the test if you are not 100% sure.)</blockquote>
<ul>
<li>
Exchange all client binaries with the new ones</li>
</ul>
<ul>
<li>
Run the testsuite again:</li>
<br>
<ul><tt>expect check.exp all 2 category COMPATIBILITY</tt></ul>
<li>
Compare results with validation run</li>
<ul>
<br>Stop if the results are not equal.</ul>
</ul>
<h3>
Check 5: General compatibility</h3>
<ul>
<li>
Shutdown the system</li>
<br>
<p>
<p>Use the testsuite to shutdown the cluster:
<br>
<ul><tt>expect check.exp kill</tt></ul>
<li>
Set up a testsuite cluster with more than one host using the modified build</li>
<br>
<p>
<p>The <a href="../testsuite/testsuite.html">Testsuite</a> documentation
is describing how this can be done. Use the <b><i>modified build</i></b>.
<br>
<ul> expect check.exp install</ul>
<p><br>The testsuite will generate a default setup file "defaults.sav"
in the testsuite directory. After that the testsuite will start the vi
command in order that the user can edit the testsuite settings. You will
be asked on which hosts you want to install a testsuite cluster and you
will have to use at least 2 for the purpose of the compatibility test.
<p>Run the testsuite with following command on your modified build:
<br>
<ul>
<li>
<tt>expect check.exp all 2 category COMPATIBILITY</tt></li>
</ul>
<li>
Compare results with validation run</li>
<ul> </ul>
Stop if the results are not equal.
<p><br>
<BR></ul>
<h3>
<a NAME="testsuite start output"></a>Testsuite start output</h3>
<blockquote>After starting the testsuite with the command
<blockquote><tt>expect check.exp all 2 category COMPATIBILITY</tt></blockquote>
the testsuite should produce the following output:</blockquote>
<center><table BORDER COLS=1 WIDTH="80%" NOSAVE >
<tr>
<td><tt>===============================================================================</tt>
<br><tt> system version : SGE 5.3 (1)
/ feature: none</tt>
<br><tt> current dir :
[testsuite_root_directory]/checktree</tt>
<br><tt> max. runlevel : day long
medium short week</tt>
<br><tt> selected runlevels : long medium short</tt>
<br><tt> categories
: COMPATIBILITY PERFORMANCE SYSTEM </tt>
<br><tt> selected categories: COMPATIBILITY </tt>
<br><tt> est. run time : 6 h 40
m</tt>
<br><tt>===============================================================================</tt>
<br><tt> 2 test(s) available in subdir: functional</tt>
<br><tt> 1 test(s) available in subdir: install_core_system</tt>
<br><tt> 0 test(s) available in subdir: performance</tt>
<br><tt> 19 test(s) available in subdir: system_tests</tt>
<br><tt>===============================================================================</tt>
<br><tt>run all tests ...</tt>
<br><tt>you have no ssh access and no root password</tt>
<br><tt>test in directory [testsuite_root_directory]/checktree/functional/access_lists </tt>
<br><tt>needs root access ...</tt>
<br><tt>root access needed, please enter root password: </tt>
<br><tt></tt>
<br> </td>
</tr>
</table></center>
<blockquote>After entering the root password the testsuite will start with
the compatibility tests.</blockquote>
<br>
<BR>
<h3>
<a NAME="notes_5_3"></a>Notes for Grid Engine release 5.3</h3>
<blockquote>Following tests may cause trouble. If one of the check functions
will report an error described in this table, the
<br>error can be ignored:
<br>
<br>
<center><table BORDER COLS=3 WIDTH="95%" NOSAVE >
<tr NOSAVE>
<td NOSAVE><b>Check name</b></td>
<td><b>Check function</b></td>
<td><b>Remarks</b></td>
</tr>
<tr>
<td><font size=-1>submit_del</font></td>
<td><font size=-1>submit_del_test</font></td>
<td><font size=-1>A job deleted immediately after submit, may stay in delete
state. A second qdel call will delete the job. This is a known problem.
The testsuite provokes this behaviour and reports errors. </font><font size=-1></font>
<p><font size=-1>The error message is "timeout waiting for end of all jobs"</font></td>
</tr>
<tr>
<td><font size=-1>qdel</font></td>
<td><font size=-1>qdel_submit_delete_when_transfered</font></td>
<td><font size=-1>See remarks for submit_del. </font><font size=-1></font>
<p><font size=-1>Error message is `timeout waiting for job "X" "leeper""`</font></td>
</tr>
<tr>
<td><font size=-1>qrsh</font></td>
<td><font size=-1>qrsh_trap</font></td>
<td><font size=-1>This test notifies the user with "test not completely
implemented" this is only a warning. </font><font size=-1></font>
<p><font size=-1>The result is listet as "unsupported tests". Any other
error should not pop up.</font></td>
</tr>
</table></center>
<font size=-1></font>
<br> </blockquote>
<ul>
<ul> </ul>
</ul>
<center>Copyright © 2001 Sun Microsystems Inc. All rights reserved.</center>
</body>
</html>
|
