Merge lp:~codehelp/lava-dispatcher/multinode-docs-update into lp:lava-dispatcher/multinode
- multinode-docs-update
- Merge into multinode
Proposed by
Neil Williams
Status: | Merged |
---|---|
Approved by: | Neil Williams |
Approved revision: | 691 |
Merged at revision: | 690 |
Proposed branch: | lp:~codehelp/lava-dispatcher/multinode-docs-update |
Merge into: | lp:lava-dispatcher/multinode |
Diff against target: |
723 lines (+369/-52) 5 files modified
doc/debugging.rst (+119/-0) doc/multinode.rst (+51/-0) doc/multinodeapi.rst (+18/-0) doc/usecaseone.rst (+95/-38) doc/usecasetwo.rst (+86/-14) |
To merge this branch: | bzr merge lp:~codehelp/lava-dispatcher/multinode-docs-update |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Milo Casagrande (community) | Approve | ||
Review via email: mp+181775@code.launchpad.net |
Commit message
Description of the change
This is the update containing the docs as shown in the demo.
To post a comment you must log in.
Preview Diff
[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1 | === added file 'doc/debugging.rst' | |||
2 | --- doc/debugging.rst 1970-01-01 00:00:00 +0000 | |||
3 | +++ doc/debugging.rst 2013-08-23 10:36:27 +0000 | |||
4 | @@ -0,0 +1,119 @@ | |||
5 | 1 | .. _debugging: | ||
6 | 2 | |||
7 | 3 | Debugging LAVA test definitions | ||
8 | 4 | ******************************* | ||
9 | 5 | |||
10 | 6 | .. _singlenode: | ||
11 | 7 | |||
12 | 8 | Convert Multi-Node jobs to single node | ||
13 | 9 | ====================================== | ||
14 | 10 | |||
15 | 11 | The scripts available in the :ref:`multinode_api` are not installed for | ||
16 | 12 | test jobs which are not part of a MultiNode group, so the job will simply | ||
17 | 13 | fail that test as a ``command not found``. | ||
18 | 14 | |||
19 | 15 | Therefore, by reversing the :ref:`changes_to_json`, a MultiNode JSON file | ||
20 | 16 | can be converted to singlenode. | ||
21 | 17 | |||
22 | 18 | Other calls which may require communication with other devices may need | ||
23 | 19 | to be removed from your YAML. This can be extended to retain a set of | ||
24 | 20 | singlenode YAML files in which new wrapper scripts and new builds are | ||
25 | 21 | tested. | ||
26 | 22 | |||
27 | 23 | The Job Definition of one job within a MultiNode group may be a good | ||
28 | 24 | starting point for creating a singlenode equivalent. | ||
29 | 25 | |||
30 | 26 | .. _set_x: | ||
31 | 27 | |||
32 | 28 | Always use set -x in wrapper scripts | ||
33 | 29 | ==================================== | ||
34 | 30 | |||
35 | 31 | By viewing the complete log, the complete processing of the wrapper script | ||
36 | 32 | becomes obvious. | ||
37 | 33 | |||
38 | 34 | :: | ||
39 | 35 | |||
40 | 36 | #!/bin/sh | ||
41 | 37 | set -e | ||
42 | 38 | set -x | ||
43 | 39 | |||
44 | 40 | .. _shell_operators: | ||
45 | 41 | |||
46 | 42 | Avoid using shell operators in YAML lines | ||
47 | 43 | ========================================= | ||
48 | 44 | |||
49 | 45 | Pipes, redirects and nested sub shells will not work reliably when put | ||
50 | 46 | directly into the YAML. Use a wrapper script (with :ref:`set -x <set_x>`). | ||
51 | 47 | |||
52 | 48 | :: | ||
53 | 49 | |||
54 | 50 | #!/bin/sh | ||
55 | 51 | |||
56 | 52 | set -e | ||
57 | 53 | set -x | ||
58 | 54 | ifconfig|grep "inet addr"|grep -v "127.0.0.1"|cut -d: -f2|cut -d' ' -f1 | ||
59 | 55 | |||
60 | 56 | Un-nested sub-shells do work:: | ||
61 | 57 | |||
62 | 58 | - lava-test-case multinode-send-network --shell lava-send network hostname=$(hostname) fqdn=$(hostname -f) | ||
63 | 59 | |||
64 | 60 | .. _check_messageid: | ||
65 | 61 | |||
66 | 62 | Check that your message ID labels are consistent | ||
67 | 63 | ================================================ | ||
68 | 64 | |||
69 | 65 | A :ref:`lava_wait` must be preceded by a :ref:`lava_send` from at least | ||
70 | 66 | one other device in the group or the waiting device will :ref:`timeout <timeouts>` | ||
71 | 67 | |||
72 | 68 | This can be a particular problem if you remove test definitions from the | ||
73 | 69 | JSON or edit a YAML file without checking other uses of the same file. | ||
74 | 70 | |||
75 | 71 | ``#`` can be used as a comment in YAML but JSON does not support | ||
76 | 72 | comments, so take care. | ||
77 | 73 | |||
78 | 74 | .. _parsers: | ||
79 | 75 | |||
80 | 76 | Test your result parsers | ||
81 | 77 | ======================== | ||
82 | 78 | |||
83 | 79 | If the YAML uses a custom result parser, configure one of your YAML files | ||
84 | 80 | to output the entire test result output to stdout so that you can | ||
85 | 81 | reliably capture a representative block of output. Test your proposed | ||
86 | 82 | result parser against the block using your favourite language. | ||
87 | 83 | |||
88 | 84 | Comment out the parser from the YAML if there are particular problems, | ||
89 | 85 | just to see what the default LAVA parsers can provide. | ||
90 | 86 | |||
91 | 87 | .. _paths: | ||
92 | 88 | |||
93 | 89 | Be obsessive about paths and scripts | ||
94 | 90 | ==================================== | ||
95 | 91 | |||
96 | 92 | * If you use ``cd`` in your YAML, always store where you were and where you end up using ``pwd``. | ||
97 | 93 | * Output your location prior to calling local wrapper scripts. | ||
98 | 94 | * Ensure that all wrapper scripts are executable in your VCS | ||
99 | 95 | * Ensure that the relevant interpreter is installed. e.g. python is not necessarily part of the test image. | ||
100 | 96 | * Consider installing ``realpath`` and use that to debug your directory structure. | ||
101 | 97 | * Avoid the temptation of using absolute paths - LAVA may need to change the absolute locations. | ||
102 | 98 | |||
103 | 99 | .. _failed_tests: | ||
104 | 100 | |||
105 | 101 | A failed test is not necessarily a bug in the test | ||
106 | 102 | ================================================== | ||
107 | 103 | |||
108 | 104 | Always check whether the test result came back as failed due to some | ||
109 | 105 | cause other than the test definition itself. Particularly with MultiNode, | ||
110 | 106 | a test result can fail due to some problem on a different board within | ||
111 | 107 | the group. | ||
112 | 108 | |||
113 | 109 | .. _json_files: | ||
114 | 110 | |||
115 | 111 | Check your JSON files | ||
116 | 112 | ===================== | ||
117 | 113 | |||
118 | 114 | Syntax problems will be picked up by LAVA when you submit but also check | ||
119 | 115 | that the URLs listed in the JSON are correct. Keep your YAML descriptions, | ||
120 | 116 | names and filenames unique so that it is easier to pick up if the JSON | ||
121 | 117 | simply calls the wrong YAML test definition. | ||
122 | 118 | |||
123 | 119 | |||
124 | 0 | 120 | ||
125 | === modified file 'doc/multinode.rst' | |||
126 | --- doc/multinode.rst 2013-08-19 10:36:07 +0000 | |||
127 | +++ doc/multinode.rst 2013-08-23 10:36:27 +0000 | |||
128 | @@ -29,6 +29,7 @@ | |||
129 | 29 | 29 | ||
130 | 30 | multinodeapi.rst | 30 | multinodeapi.rst |
131 | 31 | multinode-usecases.rst | 31 | multinode-usecases.rst |
132 | 32 | debugging.rst | ||
133 | 32 | 33 | ||
134 | 33 | Hardware requirements and virtualisation | 34 | Hardware requirements and virtualisation |
135 | 34 | **************************************** | 35 | **************************************** |
136 | @@ -70,6 +71,8 @@ | |||
137 | 70 | If more than one, but not all, roles share one particular action, that action will need to be repeated | 71 | If more than one, but not all, roles share one particular action, that action will need to be repeated |
138 | 71 | within the JSON file, once for each role using that action. | 72 | within the JSON file, once for each role using that action. |
139 | 72 | 73 | ||
140 | 74 | .. _changes_to_json: | ||
141 | 75 | |||
142 | 73 | Changes to submission JSON | 76 | Changes to submission JSON |
143 | 74 | ========================== | 77 | ========================== |
144 | 75 | 78 | ||
145 | @@ -159,6 +162,8 @@ | |||
146 | 159 | or a lava-wait will fail on any node which waits longer than the default timeout. The node will receive a failure | 162 | or a lava-wait will fail on any node which waits longer than the default timeout. The node will receive a failure |
147 | 160 | response. | 163 | response. |
148 | 161 | 164 | ||
149 | 165 | .. _timeouts: | ||
150 | 166 | |||
151 | 162 | Recommendations on timeouts | 167 | Recommendations on timeouts |
152 | 163 | =========================== | 168 | =========================== |
153 | 164 | 169 | ||
154 | @@ -178,6 +183,52 @@ | |||
155 | 178 | waiting jobs have already failed due to a problem elsewhere in the group. If timeouts are too short, | 183 | waiting jobs have already failed due to a problem elsewhere in the group. If timeouts are too short, |
156 | 179 | jobs will fail unnecessarily. | 184 | jobs will fail unnecessarily. |
157 | 180 | 185 | ||
158 | 186 | Balancing timeouts | ||
159 | 187 | ^^^^^^^^^^^^^^^^^^ | ||
160 | 188 | |||
161 | 189 | Individual actions and commands can have differing timeouts, so avoid the temptation to change the | ||
162 | 190 | default timeout when a particular action times out in a Multi-Node job. If a particular ``lava-test-shell`` | ||
163 | 191 | takes a long time, set an explicit timeout for that particular action: | ||
164 | 192 | |||
165 | 193 | :: | ||
166 | 194 | |||
167 | 195 | { | ||
168 | 196 | "timeout": 900, | ||
169 | 197 | "job_name": "netperf multinode tests", | ||
170 | 198 | "logging_level": "DEBUG", | ||
171 | 199 | } | ||
172 | 200 | |||
173 | 201 | |||
174 | 202 | :: | ||
175 | 203 | |||
176 | 204 | { | ||
177 | 205 | "command": "lava_test_shell", | ||
178 | 206 | "parameters": { | ||
179 | 207 | "testdef_repos": [ | ||
180 | 208 | { | ||
181 | 209 | "git-repo": "git://git.linaro.org/people/guoqing.zhu/netperf-multinode.git", | ||
182 | 210 | "testdef": "netperf-multinode-c-network.yaml" | ||
183 | 211 | } | ||
184 | 212 | ], | ||
185 | 213 | "timeout": 2400, | ||
186 | 214 | "role": "client" | ||
187 | 215 | } | ||
188 | 216 | }, | ||
189 | 217 | { | ||
190 | 218 | "command": "lava_test_shell", | ||
191 | 219 | "parameters": { | ||
192 | 220 | "testdef_repos": [ | ||
193 | 221 | { | ||
194 | 222 | "git-repo": "git://git.linaro.org/people/guoqing.zhu/netperf-multinode.git", | ||
195 | 223 | "testdef": "netperf-multinode-s-network.yaml" | ||
196 | 224 | } | ||
197 | 225 | ], | ||
198 | 226 | "timeout": 1800, | ||
199 | 227 | "role": "server" | ||
200 | 228 | } | ||
201 | 229 | }, | ||
202 | 230 | |||
203 | 231 | |||
204 | 181 | Running a server on the device-under-test | 232 | Running a server on the device-under-test |
205 | 182 | ***************************************** | 233 | ***************************************** |
206 | 183 | 234 | ||
207 | 184 | 235 | ||
208 | === modified file 'doc/multinodeapi.rst' | |||
209 | --- doc/multinodeapi.rst 2013-08-19 10:36:07 +0000 | |||
210 | +++ doc/multinodeapi.rst 2013-08-23 10:36:27 +0000 | |||
211 | @@ -1,3 +1,5 @@ | |||
212 | 1 | .. _multinode_api: | ||
213 | 2 | |||
214 | 1 | MultiNode API | 3 | MultiNode API |
215 | 2 | ============= | 4 | ============= |
216 | 3 | 5 | ||
217 | @@ -6,6 +8,8 @@ | |||
218 | 6 | definitions which need to transfer files, long messages or other large amounts of data need to set up their | 8 | definitions which need to transfer files, long messages or other large amounts of data need to set up their |
219 | 7 | own network configuration, access and download methods and do the transfer in the test definition. | 9 | own network configuration, access and download methods and do the transfer in the test definition. |
220 | 8 | 10 | ||
221 | 11 | .. _lava_self: | ||
222 | 12 | |||
223 | 9 | lava-self | 13 | lava-self |
224 | 10 | --------- | 14 | --------- |
225 | 11 | 15 | ||
226 | @@ -13,6 +17,8 @@ | |||
227 | 13 | 17 | ||
228 | 14 | Usage: ``lava-self`` | 18 | Usage: ``lava-self`` |
229 | 15 | 19 | ||
230 | 20 | .. _lava_role: | ||
231 | 21 | |||
232 | 16 | lava-role | 22 | lava-role |
233 | 17 | --------- | 23 | --------- |
234 | 18 | 24 | ||
235 | @@ -25,6 +31,8 @@ | |||
236 | 25 | 31 | ||
237 | 26 | $ ./run-$(lava-role) | 32 | $ ./run-$(lava-role) |
238 | 27 | 33 | ||
239 | 34 | .. _lava-group: | ||
240 | 35 | |||
241 | 28 | lava-group | 36 | lava-group |
242 | 29 | ---------- | 37 | ---------- |
243 | 30 | 38 | ||
244 | @@ -42,6 +50,8 @@ | |||
245 | 42 | highbank02 backend | 50 | highbank02 backend |
246 | 43 | highbank03 backend | 51 | highbank03 backend |
247 | 44 | 52 | ||
248 | 53 | .. _lava_send: | ||
249 | 54 | |||
250 | 45 | lava-send | 55 | lava-send |
251 | 46 | --------- | 56 | --------- |
252 | 47 | 57 | ||
253 | @@ -55,6 +65,8 @@ | |||
254 | 55 | Examples will be provided below, together with ``lava-wait`` and | 65 | Examples will be provided below, together with ``lava-wait`` and |
255 | 56 | ``lava-wait-all``. | 66 | ``lava-wait-all``. |
256 | 57 | 67 | ||
257 | 68 | .. _lava_wait: | ||
258 | 69 | |||
259 | 58 | lava-wait | 70 | lava-wait |
260 | 59 | --------- | 71 | --------- |
261 | 60 | 72 | ||
262 | @@ -75,6 +87,8 @@ | |||
263 | 75 | will be returned by subsequent calls to ``lava-wait`` for that message | 87 | will be returned by subsequent calls to ``lava-wait`` for that message |
264 | 76 | ID. Use a different message ID to collate different message data. | 88 | ID. Use a different message ID to collate different message data. |
265 | 77 | 89 | ||
266 | 90 | .. _lava_wait_all: | ||
267 | 91 | |||
268 | 78 | lava-wait-all | 92 | lava-wait-all |
269 | 79 | ------------- | 93 | ------------- |
270 | 80 | 94 | ||
271 | @@ -108,6 +122,8 @@ | |||
272 | 108 | As with ``lava-wait``, the message ID is persistent for the duration of | 122 | As with ``lava-wait``, the message ID is persistent for the duration of |
273 | 109 | the MultiNode group. | 123 | the MultiNode group. |
274 | 110 | 124 | ||
275 | 125 | .. _lava_sync: | ||
276 | 126 | |||
277 | 111 | lava-sync | 127 | lava-sync |
278 | 112 | --------- | 128 | --------- |
279 | 113 | 129 | ||
280 | @@ -119,6 +135,8 @@ | |||
281 | 119 | ``lava-sync foo`` is effectively the same as ``lava-send foo`` followed | 135 | ``lava-sync foo`` is effectively the same as ``lava-send foo`` followed |
282 | 120 | by ``lava-wait-all foo``. | 136 | by ``lava-wait-all foo``. |
283 | 121 | 137 | ||
284 | 138 | .. _lava_network: | ||
285 | 139 | |||
286 | 122 | lava-network | 140 | lava-network |
287 | 123 | ------------ | 141 | ------------ |
288 | 124 | 142 | ||
289 | 125 | 143 | ||
290 | === modified file 'doc/usecaseone.rst' | |||
291 | --- doc/usecaseone.rst 2013-08-19 10:36:07 +0000 | |||
292 | +++ doc/usecaseone.rst 2013-08-23 10:36:27 +0000 | |||
293 | @@ -1,34 +1,39 @@ | |||
294 | 1 | .. _use_case_one: | ||
295 | 2 | |||
296 | 1 | Use Case One - Setting up a simple client:server test definition. | 3 | Use Case One - Setting up a simple client:server test definition. |
297 | 2 | ***************************************************************** | 4 | ***************************************************************** |
298 | 3 | 5 | ||
300 | 4 | One device needs to obtain / prepare some data and then make the data | 6 | One device needs to obtain / prepare some data and then make the data |
301 | 5 | available to another device in the same group. | 7 | available to another device in the same group. |
302 | 6 | 8 | ||
303 | 7 | Source Code | 9 | Source Code |
304 | 8 | =========== | 10 | =========== |
305 | 9 | 11 | ||
307 | 10 | * The YAML snippets in this example are not complete, for a working example of the code, see: | 12 | * The YAML snippets in this example are not complete, for a working example of the code, see: |
308 | 11 | 13 | ||
309 | 12 | https://git.linaro.org/gitweb?p=people/neilwilliams/multinode-yaml.git;a=blob_plain;f=forwarder.yaml;hb=refs/heads/master | 14 | https://git.linaro.org/gitweb?p=people/neilwilliams/multinode-yaml.git;a=blob_plain;f=forwarder.yaml;hb=refs/heads/master |
310 | 13 | 15 | ||
311 | 14 | https://git.linaro.org/gitweb?p=people/neilwilliams/multinode-yaml.git;a=blob_plain;f=receiver.yaml;hb=refs/heads/master | 16 | https://git.linaro.org/gitweb?p=people/neilwilliams/multinode-yaml.git;a=blob_plain;f=receiver.yaml;hb=refs/heads/master |
312 | 15 | 17 | ||
314 | 16 | https://git.linaro.org/gitweb?p=people/neilwilliams/multinode-yaml.git;a=blob_plain;f=json/kvm-beagleblack-group.json;hb=HEAD | 18 | https://git.linaro.org/gitweb?p=people/neilwilliams/multinode-yaml.git;a=blob_plain;f=json/beagleblack-use-case.json;hb=HEAD |
315 | 17 | 19 | ||
316 | 18 | Requirements | 20 | Requirements |
317 | 19 | ============ | 21 | ============ |
318 | 20 | 22 | ||
324 | 21 | * A mechanism to obtain the data, presumably from some third-party source | 23 | 1. A mechanism to obtain the data, presumably from some third-party source |
325 | 22 | * A sync to ensure that the file is ready to be offered to the other device | 24 | 2. A sync to ensure that the file is ready to be offered to the other device |
326 | 23 | * This ensures that the attempt to receive does not start early | 25 | |
327 | 24 | * A message to the original board that the data has been received and verified | 26 | 2.1. This ensures that the attempt to receive does not start early |
328 | 25 | * This ensures that any cleanup of the data does not happen before the transfer is complete. | 27 | |
329 | 28 | 3. A message to the original board that the data has been received and verified | ||
330 | 29 | |||
331 | 30 | 3.1. This ensures that any cleanup of the data does not happen before the transfer is complete. | ||
332 | 26 | 31 | ||
333 | 27 | Methods | 32 | Methods |
334 | 28 | ======= | 33 | ======= |
335 | 29 | 34 | ||
338 | 30 | * Install a package which can obtain the data from the third party source | 35 | * Install a package which can obtain the data from the third party source |
339 | 31 | * Install a package which can provide the means to get the data to the other board | 36 | * Install a package which can provide the means to get the data to the other board |
340 | 32 | 37 | ||
341 | 33 | Control flow | 38 | Control flow |
342 | 34 | ============ | 39 | ============ |
343 | @@ -66,8 +71,8 @@ | |||
344 | 66 | of the filter. To start each YAML file, ensure that the metadata contains | 71 | of the filter. To start each YAML file, ensure that the metadata contains |
345 | 67 | two metadata fields: | 72 | two metadata fields: |
346 | 68 | 73 | ||
349 | 69 | * format - **Lava-Test Test Definition 1.0** | 74 | * format : **Lava-Test Test Definition 1.0** |
350 | 70 | * description - your own descriptive text | 75 | * description : your own descriptive text |
351 | 71 | 76 | ||
352 | 72 | It is useful to also add the maintainer field with your email address | 77 | It is useful to also add the maintainer field with your email address |
353 | 73 | as this will be needed later if the test is to be added to one of the | 78 | as this will be needed later if the test is to be added to one of the |
354 | @@ -82,10 +87,50 @@ | |||
355 | 82 | maintainer: | 87 | maintainer: |
356 | 83 | - neil.williams@linaro.org | 88 | - neil.williams@linaro.org |
357 | 84 | 89 | ||
358 | 90 | Installing packages for use in a test | ||
359 | 91 | ------------------------------------- | ||
360 | 92 | |||
361 | 93 | If your test image raises a usable network interface by default on boot, | ||
362 | 94 | the YAML can specify a list of packages which need to be installed for | ||
363 | 95 | this test definition: | ||
364 | 96 | |||
365 | 97 | :: | ||
366 | 98 | |||
367 | 99 | install: | ||
368 | 100 | deps: | ||
369 | 101 | - wget | ||
370 | 102 | - apache2 | ||
371 | 103 | |||
372 | 104 | If your test needs to raise the network interface itself, the package | ||
373 | 105 | installation will need to be done in the run steps:: | ||
374 | 106 | |||
375 | 107 | run: | ||
376 | 108 | steps: | ||
377 | 109 | - lava-test-case linux-linaro-ubuntu-route-ifconfig-up --shell ifconfig eth0 up | ||
378 | 110 | - lava-test-case apt-update --shell apt-get update | ||
379 | 111 | - lava-test-case install-deps --shell apt-get -y install wget apache2 | ||
380 | 112 | |||
381 | 113 | Note that although KVM devices can use apt, the network interface fails | ||
382 | 114 | the LAVA test, so use the manual install steps for non-bridged KVM devices. | ||
383 | 85 | 115 | ||
384 | 86 | Preparing the test to send data | 116 | Preparing the test to send data |
385 | 87 | ------------------------------- | 117 | ------------------------------- |
386 | 88 | 118 | ||
387 | 119 | ``modify-data.sh`` would, presumably, unpack the data, modify it in | ||
388 | 120 | some way and pack it back up again. In this example, it would be a no-op | ||
389 | 121 | but note that it still needs to exist in the top level directory of your | ||
390 | 122 | VCS repo and be executable. | ||
391 | 123 | |||
392 | 124 | Any packages required by ``modify-data.sh`` need to be added to the install | ||
393 | 125 | deps of sender.yaml. Providing useful contents of ``modify-data.sh`` is | ||
394 | 126 | left as an exercise for the reader. | ||
395 | 127 | |||
396 | 128 | Modification happens before the :ref:`lava_sync` ``download`` which tells the | ||
397 | 129 | receiver that the data is ready to be transferred. | ||
398 | 130 | |||
399 | 131 | The sender then waits for the receiver to acknowledge a correct download | ||
400 | 132 | using :ref:`lava_sync` ``received`` and cleans up. | ||
401 | 133 | |||
402 | 89 | sender.yaml | 134 | sender.yaml |
403 | 90 | ^^^^^^^^^^^ | 135 | ^^^^^^^^^^^ |
404 | 91 | 136 | ||
405 | @@ -98,7 +143,6 @@ | |||
406 | 98 | 143 | ||
407 | 99 | run: | 144 | run: |
408 | 100 | steps: | 145 | steps: |
409 | 101 | - lava-test-case linux-linaro-ubuntu-route-ifconfig-up --shell ifconfig eth0 up | ||
410 | 102 | - lava-test-case multinode-network --shell lava-network broadcast eth0 | 146 | - lava-test-case multinode-network --shell lava-network broadcast eth0 |
411 | 103 | - lava-test-case wget-file --shell wget -O /var/www/testfile http://releases.linaro.org/latest/android/arndale/userdata.tar.bz2 | 147 | - lava-test-case wget-file --shell wget -O /var/www/testfile http://releases.linaro.org/latest/android/arndale/userdata.tar.bz2 |
412 | 104 | - ./modify-data.sh | 148 | - ./modify-data.sh |
413 | @@ -112,12 +156,10 @@ | |||
414 | 112 | The receiver needs to know where to find the data. The sender can ensure that the | 156 | The receiver needs to know where to find the data. The sender can ensure that the |
415 | 113 | file is in a particular location, it is up to the YAML to get the rest of the | 157 | file is in a particular location, it is up to the YAML to get the rest of the |
416 | 114 | information of the network address of the sender. This example assumes that the | 158 | information of the network address of the sender. This example assumes that the |
418 | 115 | data is modified in some undisclosed manner by the ```./modify-data.sh``` | 159 | data is modified in some undisclosed manner by the ``./modify-data.sh`` |
419 | 116 | script which is part of your testdef_repo before the receiver is notified. | 160 | script which is part of your testdef_repo before the receiver is notified. |
420 | 117 | Any packages required by ```modify-data.sh``` need to be added to the install | ||
421 | 118 | deps of sender.yaml. The contents of ```modify-data.sh``` are left as an exercise for the reader. | ||
422 | 119 | 161 | ||
424 | 120 | The LAVA MultiNode API provides ways of querying the network information of devices | 162 | The LAVA :ref:`multinode_api` provides ways of querying the network information of devices |
425 | 121 | within the group. In order to offer the data via apache, the sender needs to | 163 | within the group. In order to offer the data via apache, the sender needs to |
426 | 122 | raise a suitable network interface, so it calls ifconfig as a lava test case | 164 | raise a suitable network interface, so it calls ifconfig as a lava test case |
427 | 123 | first and then uses the lava-network API call to broadcast network information | 165 | first and then uses the lava-network API call to broadcast network information |
428 | @@ -159,33 +201,40 @@ | |||
429 | 159 | get-data.sh | 201 | get-data.sh |
430 | 160 | ^^^^^^^^^^^ | 202 | ^^^^^^^^^^^ |
431 | 161 | 203 | ||
432 | 204 | Always use **set -x** in any wrapper / helper scripts which you expect | ||
433 | 205 | to use in a test run to be able to debug test failures. | ||
434 | 206 | |||
435 | 207 | Ensure that the scripts are marked as executable in your VCS and | ||
436 | 208 | that the appropriate interpreter is installed in your test image. | ||
437 | 209 | |||
438 | 162 | :: | 210 | :: |
439 | 163 | 211 | ||
440 | 164 | #!/bin/sh | 212 | #!/bin/sh |
441 | 165 | set -e | 213 | set -e |
443 | 166 | DEVICE=`lava-group | grep -m1 -v kvm|cut -f2` | 214 | set -x |
444 | 215 | DEVICE=`lava-group | grep -m1 receiver|cut -f2` | ||
445 | 167 | SOURCE=`lava-network query $DEVICE ipv4|grep -v LAVA|cut -d: -f2` | 216 | SOURCE=`lava-network query $DEVICE ipv4|grep -v LAVA|cut -d: -f2` |
446 | 168 | wget -O /tmp/testfile http://${SOURCE}/testfile | 217 | wget -O /tmp/testfile http://${SOURCE}/testfile |
447 | 169 | 218 | ||
448 | 170 | 219 | ||
452 | 171 | The ```$DEVICE``` simply matches the first device name in this group | 220 | The ``$DEVICE`` simply matches the first device name in this group |
453 | 172 | which contains the string 'kvm' and returns the full name of that device, | 221 | which contains the string 'receiver' (which comes from the ``role`` |
454 | 173 | e.g. multinode-kvm02 | 222 | specified in the JSON) and returns the full name of that device, |
455 | 223 | e.g. multinode-kvm02 or staging-beagleblack03 | ||
456 | 174 | 224 | ||
457 | 175 | This device name is then passed to lava-network query to get the ipv4 | 225 | This device name is then passed to lava-network query to get the ipv4 |
459 | 176 | details of that device within this group. The value of ```$SOURCE``` | 226 | details of that device within this group. The value of ``$SOURCE`` |
460 | 177 | is an IPv4 address of the sender (assuming that your JSON has defined a | 227 | is an IPv4 address of the sender (assuming that your JSON has defined a |
463 | 178 | device_type for the sender as a device which would contain | 228 | role for the sender which would contain the 'receiver' string in the name.) |
462 | 179 | the 'kvm' string in the name.) | ||
464 | 180 | 229 | ||
466 | 181 | Finally, ```get-data.sh``` does the work of receiving the data from | 230 | Finally, ``get-data.sh`` does the work of receiving the data from |
467 | 182 | the sender. The verification of the data is left as an exercise for | 231 | the sender. The verification of the data is left as an exercise for |
468 | 183 | the reader - one simple method would be for the sender to checksum the | 232 | the reader - one simple method would be for the sender to checksum the |
471 | 184 | (modified) data and use ```lava-send``` to make that checksum available | 233 | (modified) data and use ``lava-send`` to make that checksum available |
472 | 185 | to devices within the group. The receiver can then use ```lava-wait``` | 234 | to devices within the group. The receiver can then use ``lava-wait`` |
473 | 186 | to get that checksum. | 235 | to get that checksum. |
474 | 187 | 236 | ||
476 | 188 | Once ```get-data.sh``` returns, the receiver notifies the sender that | 237 | Once ``get-data.sh`` returns, the receiver notifies the sender that |
477 | 189 | the transfer is complete, processes the data as it sees fit and cleans up. | 238 | the transfer is complete, processes the data as it sees fit and cleans up. |
478 | 190 | 239 | ||
479 | 191 | Preparing the JSON | 240 | Preparing the JSON |
480 | @@ -193,7 +242,7 @@ | |||
481 | 193 | 242 | ||
482 | 194 | The JSON ties the YAML test definition with the hardware and software to | 243 | The JSON ties the YAML test definition with the hardware and software to |
483 | 195 | run the test definition. The JSON is also where multiple test | 244 | run the test definition. The JSON is also where multiple test |
485 | 196 | definitions are combined into a single !MultiNode test. | 245 | definitions are combined into a single MultiNode test. |
486 | 197 | 246 | ||
487 | 198 | General settings | 247 | General settings |
488 | 199 | ---------------- | 248 | ---------------- |
489 | @@ -289,8 +338,7 @@ | |||
490 | 289 | If any action has no role specified, it will be actioned for all roles. | 338 | If any action has no role specified, it will be actioned for all roles. |
491 | 290 | 339 | ||
492 | 291 | For Use Case One, we have a different YAML file for each role, so | 340 | For Use Case One, we have a different YAML file for each role, so |
495 | 292 | we have two lava_test_shell commands. (The content happens to be the | 341 | we have two lava_test_shell commands. |
494 | 293 | same in this example.) | ||
496 | 294 | 342 | ||
497 | 295 | :: | 343 | :: |
498 | 296 | 344 | ||
499 | @@ -326,7 +374,8 @@ | |||
500 | 326 | ^^^^^^^^^^^^^^ | 374 | ^^^^^^^^^^^^^^ |
501 | 327 | 375 | ||
502 | 328 | The results for the entire group get aggregated into a single result | 376 | The results for the entire group get aggregated into a single result |
504 | 329 | bundle. | 377 | bundle. Ensure that the bundle stream exists on the specified server |
505 | 378 | and that you have permission to add to that stream. | ||
506 | 330 | 379 | ||
507 | 331 | :: | 380 | :: |
508 | 332 | 381 | ||
509 | @@ -334,7 +383,7 @@ | |||
510 | 334 | { | 383 | { |
511 | 335 | "command": "submit_results_on_host", | 384 | "command": "submit_results_on_host", |
512 | 336 | "parameters": { | 385 | "parameters": { |
514 | 337 | "stream": "/anonymous/instance-manager/", | 386 | "stream": "/anonymous/use-cases/", |
515 | 338 | "server": "http://validation.linaro.org/RPC2/" | 387 | "server": "http://validation.linaro.org/RPC2/" |
516 | 339 | } | 388 | } |
517 | 340 | } | 389 | } |
518 | @@ -343,7 +392,7 @@ | |||
519 | 343 | Prepare a filter for the results | 392 | Prepare a filter for the results |
520 | 344 | ================================ | 393 | ================================ |
521 | 345 | 394 | ||
523 | 346 | Now decide how your are going to analyse the results of tests using | 395 | Now decide how you are going to analyse the results of tests using |
524 | 347 | this definition, using the name of the test definition specified in | 396 | this definition, using the name of the test definition specified in |
525 | 348 | the YAML metadata. | 397 | the YAML metadata. |
526 | 349 | 398 | ||
527 | @@ -385,7 +434,7 @@ | |||
528 | 385 | 434 | ||
529 | 386 | On the website for the instance running the tests, click on Dashboard | 435 | On the website for the instance running the tests, click on Dashboard |
530 | 387 | and Filters. If you have permissions, there will be a link entitled | 436 | and Filters. If you have permissions, there will be a link entitled |
532 | 388 | *Add new filter...*. | 437 | *Add new filter...*. |
533 | 389 | 438 | ||
534 | 390 | The filter name should include most of the data about what this filter | 439 | The filter name should include most of the data about what this filter |
535 | 391 | is intended to do, without whitespace. This name will be preserved through | 440 | is intended to do, without whitespace. This name will be preserved through |
536 | @@ -406,13 +455,13 @@ | |||
537 | 406 | 455 | ||
538 | 407 | Within a test definition, a filter can also select only particular test | 456 | Within a test definition, a filter can also select only particular test |
539 | 408 | cases. In this Use Case, for example, the filter could choose only the | 457 | cases. In this Use Case, for example, the filter could choose only the |
541 | 409 | ```multinode-network```, ```multinode-get-network``` or ```file-sync``` | 458 | ``multinode-network``, ``multinode-get-network`` or ``file-sync`` |
542 | 410 | test cases. Continue to add tests and/or test cases - the more tests | 459 | test cases. Continue to add tests and/or test cases - the more tests |
543 | 411 | and/or test cases are added to the filter, the fewer results will | 460 | and/or test cases are added to the filter, the fewer results will |
544 | 412 | match. | 461 | match. |
545 | 413 | 462 | ||
546 | 414 | Click the *Preview* button to apply the filter to the current set of | 463 | Click the *Preview* button to apply the filter to the current set of |
548 | 415 | results **without saving the filter**. | 464 | results **without saving the filter**. |
549 | 416 | 465 | ||
550 | 417 | In the preview, if there are columns with no data or rows with no data | 466 | In the preview, if there are columns with no data or rows with no data |
551 | 418 | for specific columns, these will show up as missing data in the filter | 467 | for specific columns, these will show up as missing data in the filter |
552 | @@ -450,7 +499,7 @@ | |||
553 | 450 | 499 | ||
554 | 451 | The full version of this use case are available: | 500 | The full version of this use case are available: |
555 | 452 | 501 | ||
557 | 453 | http://git.linaro.org/gitweb?p=people/neilwilliams/multinode-yaml.git;a=blob_plain;f=json/kvm-beagleblack-group.json;hb=refs/heads/master | 502 | http://git.linaro.org/gitweb?p=people/neilwilliams/multinode-yaml.git;a=blob_plain;f=json/kvm-beagleblack-group.json;hb=HEAD |
558 | 454 | 503 | ||
559 | 455 | Example test results are visible here: | 504 | Example test results are visible here: |
560 | 456 | 505 | ||
561 | @@ -462,3 +511,11 @@ | |||
562 | 462 | did not have a bridged configuration, so the internal networking of the kvm meant | 511 | did not have a bridged configuration, so the internal networking of the kvm meant |
563 | 463 | that although the KVM could connect to the beaglebone-black, the beaglebone-black | 512 | that although the KVM could connect to the beaglebone-black, the beaglebone-black |
564 | 464 | could not connect to the kvm. | 513 | could not connect to the kvm. |
565 | 514 | |||
566 | 515 | https://git.linaro.org/gitweb?p=people/neilwilliams/multinode-yaml.git;a=blob_plain;f=json/beagleblack-use-case.json;hb=HEAD | ||
567 | 516 | |||
568 | 517 | https://staging.validation.linaro.org/dashboard/image-reports/beagleblack-usecase | ||
569 | 518 | |||
570 | 519 | https://staging.validation.linaro.org/dashboard/streams/anonymous/codehelp/bundles/cf4eb9e0022232e97aaec2737b3cd436cd37ab14/ | ||
571 | 520 | |||
572 | 521 | This example uses two beaglebone-black devices. | ||
573 | 465 | 522 | ||
574 | === modified file 'doc/usecasetwo.rst' | |||
575 | --- doc/usecasetwo.rst 2013-08-19 10:36:07 +0000 | |||
576 | +++ doc/usecasetwo.rst 2013-08-23 10:36:27 +0000 | |||
577 | @@ -1,3 +1,5 @@ | |||
578 | 1 | .. _use_case_two: | ||
579 | 2 | |||
580 | 1 | Use Case Two - Setting up the same job on multiple devices | 3 | Use Case Two - Setting up the same job on multiple devices |
581 | 2 | ********************************************************** | 4 | ********************************************************** |
582 | 3 | 5 | ||
583 | @@ -7,7 +9,7 @@ | |||
584 | 7 | Source Code | 9 | Source Code |
585 | 8 | =========== | 10 | =========== |
586 | 9 | 11 | ||
588 | 10 | The test definition itself could be an unchanged singlenode test definition, e.g. | 12 | The test definition itself could be an unchanged singlenode test definition, e.g. |
589 | 11 | 13 | ||
590 | 12 | https://git.linaro.org/gitweb?p=qa/test-definitions.git;a=blob_plain;f=ubuntu/smoke-tests-basic.yaml;hb=refs/heads/master | 14 | https://git.linaro.org/gitweb?p=qa/test-definitions.git;a=blob_plain;f=ubuntu/smoke-tests-basic.yaml;hb=refs/heads/master |
591 | 13 | 15 | ||
592 | @@ -30,10 +32,9 @@ | |||
593 | 30 | Preparing the YAML | 32 | Preparing the YAML |
594 | 31 | ================== | 33 | ================== |
595 | 32 | 34 | ||
600 | 33 | In this use case, the same YAML file is to be used to test multiple devices. | 35 | In the first part of this use case, the same YAML file is to be used to |
601 | 34 | Select your YAML file and, if appropriate, edit the name in the metadata. | 36 | test multiple devices. Select your YAML file and, if appropriate, edit |
602 | 35 | 37 | the name in the metadata. | |
599 | 36 | TBD: MultiNode API | ||
603 | 37 | 38 | ||
604 | 38 | Preparing the JSON | 39 | Preparing the JSON |
605 | 39 | =================== | 40 | =================== |
606 | @@ -41,8 +42,8 @@ | |||
607 | 41 | The change from a standard single-node JSON file is to expand the device_type | 42 | The change from a standard single-node JSON file is to expand the device_type |
608 | 42 | or device field to a device_group. | 43 | or device field to a device_group. |
609 | 43 | 44 | ||
612 | 44 | The change for multiple devices in MultiNode is within the ```device_group```. To run the test | 45 | The change for multiple devices in MultiNode is within the ``device_group``. To run the test |
613 | 45 | multiple devices of the same type, simply increase the ```count``: | 46 | multiple devices of the same type, simply increase the ``count``: |
614 | 46 | 47 | ||
615 | 47 | :: | 48 | :: |
616 | 48 | 49 | ||
617 | @@ -55,15 +56,15 @@ | |||
618 | 55 | "tags": [ | 56 | "tags": [ |
619 | 56 | "use-case-two" | 57 | "use-case-two" |
620 | 57 | ] | 58 | ] |
622 | 58 | } | 59 | } |
623 | 59 | } | 60 | } |
624 | 60 | 61 | ||
627 | 61 | If the rest of the JSON refers to a ```role``` other than the one specified | 62 | If the rest of the JSON refers to a ``role`` other than the one specified |
628 | 62 | in the ```device_group```, those JSON sections are ignored. | 63 | in the ``device_group``, those JSON sections are ignored. |
629 | 63 | 64 | ||
633 | 64 | If other actions in the JSON do not mention a ```role```, the action will | 65 | If other actions in the JSON do not mention a ``role``, the action will |
634 | 65 | occur on all devices in the ```device_group```. So with a single role, | 66 | occur on all devices in the ``device_group``. So with a single role, |
635 | 66 | it only matters that a role exists in the ```device_group```. | 67 | it only matters that a role exists in the ``device_group``. |
636 | 67 | 68 | ||
637 | 68 | actions | 69 | actions |
638 | 69 | ------- | 70 | ------- |
639 | @@ -136,13 +137,84 @@ | |||
640 | 136 | Prepare a filter for the results | 137 | Prepare a filter for the results |
641 | 137 | ================================ | 138 | ================================ |
642 | 138 | 139 | ||
644 | 139 | The filter for this use case uses a ```required attribute``` | 140 | The filter for this use case uses a ``required attribute`` |
645 | 140 | of **target.device_type** to only show results for the specified | 141 | of **target.device_type** to only show results for the specified |
646 | 141 | devices (to cover reuse of the YAML on other boards later). | 142 | devices (to cover reuse of the YAML on other boards later). |
647 | 142 | 143 | ||
648 | 143 | It is also possible to add a second filter which matches a specific **target** | 144 | It is also possible to add a second filter which matches a specific **target** |
649 | 144 | device. | 145 | device. |
650 | 145 | 146 | ||
651 | 147 | Adding synchronisation | ||
652 | 148 | ====================== | ||
653 | 149 | |||
654 | 150 | So far, the multiple devices have been started together but then had no | ||
655 | 151 | further interaction. | ||
656 | 152 | |||
657 | 153 | The :ref:`multinode_api` supports communication between devices within | ||
658 | 154 | a group and provides synchronisation primitives. The simplest of these | ||
659 | 155 | primitives, :ref:`lava_sync` was used in :ref:`use_case_one` but there are more | ||
660 | 156 | possibilities available. | ||
661 | 157 | |||
662 | 158 | :ref:`lava_sync` is a special case of a :ref:`lava_send` followed by a | ||
663 | 159 | :ref:`lava_wait_all`. | ||
664 | 160 | |||
665 | 161 | Sending messages | ||
666 | 162 | ---------------- | ||
667 | 163 | |||
668 | 164 | Messages can be sent using :ref:`lava_send` which is a non-blocking call. | ||
669 | 165 | At a later point, another device in the group can collect the message | ||
670 | 166 | using ``lava-wait`` or ``lava-wait-all`` which will block until | ||
671 | 167 | the message is available. | ||
672 | 168 | |||
673 | 169 | The message can be a simple identifier (e.g. 'download' or 'ready') and | ||
674 | 170 | is visible to all devices in the group. | ||
675 | 171 | |||
676 | 172 | Key value pairs can also be sent using the API to broadcast particular | ||
677 | 173 | information. | ||
678 | 174 | |||
679 | 175 | If multiple devices send the same message ID, the data is collated by | ||
680 | 176 | the LAVA Coordinator. Key value pairs sent with any message ID are | ||
681 | 177 | tagged with the device name which sent the key value pairs. | ||
682 | 178 | |||
683 | 179 | Receiving messages | ||
684 | 180 | ------------------ | ||
685 | 181 | |||
686 | 182 | Message reception will block until the message is available. | ||
687 | 183 | |||
688 | 184 | For :ref:`lava_wait`, the message is deemed available as soon as any device | ||
689 | 185 | in the group has sent a message with the matching ID. If no devices have | ||
690 | 186 | sent such a message, any device asking for ``lava-wait`` on that ID | ||
691 | 187 | will block until a different board uses ``lava-send`` with the expected | ||
692 | 188 | message ID. | ||
693 | 189 | |||
694 | 190 | For :ref:`lava_wait_all`, the message is only deemed available if **all | ||
695 | 191 | devices in the group** have already sent a message with the expected message | ||
696 | 192 | ID. Therefore, using ``lava-wait-all`` requires a preceding | ||
697 | 193 | ``lava-send``. | ||
698 | 194 | |||
699 | 195 | When using ``lava-wait-all MESSAGEID ROLE``, the message is only deemed | ||
700 | 196 | available if **all devices with the matching role in the group** have | ||
701 | 197 | sent a message with the expected message ID. If the receiving device has | ||
702 | 198 | the specified role, that device must use a ``lava-send`` for the same | ||
703 | 199 | message ID before using ``lava-wait-all MESSAGEID ROLE``. | ||
704 | 200 | |||
705 | 201 | :: | ||
706 | 202 | |||
707 | 203 | - lava-test-case multinode-send-network --shell lava-send ready | ||
708 | 204 | - lava-test-case multinode-get-network --shell lava-wait ready | ||
709 | 205 | |||
710 | 206 | It is up to the test writer to ensure that when :ref:`lava_wait` is used, | ||
711 | 207 | that the message ID is sufficiently unique that the first use of that | ||
712 | 208 | message ID denotes the correct point in the YAML. | ||
713 | 209 | |||
714 | 210 | :: | ||
715 | 211 | |||
716 | 212 | - lava-test-case multinode-send-message --shell lava-send sending source=$(lava-self) role=$(lava-role) hostname=$(hostname -f) kernver=$(uname -r) kernhost=$(uname -n) | ||
717 | 213 | - lava-test-case multinode-wait-message --shell lava-wait-all sending | ||
718 | 214 | |||
719 | 215 | This example will wait until all devices in the group have sent the | ||
720 | 216 | message ID ''sending'' (with or without the associated key value pairs). | ||
721 | 217 | |||
722 | 146 | Summary | 218 | Summary |
723 | 147 | ======= | 219 | ======= |
724 | 148 | 220 |
It looked good on the demo, and going through it I do not see anything broken or wrong.
So, +1 from me.