November 2012 - LNST-developers - Fedora Mailing-Lists

[lnst] Added test writing howto to documenation.

by Jiří Pírko

commit 24305e062fbff3b03d70e7d1023bef24930927dc Author: Jan Tluka <jtluka(a)redhat.com> Date: Tue Nov 6 15:17:44 2012 +0100 Added test writing howto to documenation. Signed-off-by: Jan Tluka <jtluka(a)redhat.com> Documentation/LNSTIntro.html | 187 +++++++++++++++++++++++++++++++++++++++++- 1 files changed, 186 insertions(+), 1 deletions(-) --- diff --git a/Documentation/LNSTIntro.html b/Documentation/LNSTIntro.html index 8df17b1..c83d03f 100644 --- a/Documentation/LNSTIntro.html +++ b/Documentation/LNSTIntro.html @@ -483,7 +483,192 @@ Example (peanut.xml): <hr /> -<h2>Writing a test</h2> +<h2>Writing a test for LNST</h2> + +In this chapter I'm going to guide you through the process of writing a test for the LNST framework. + +<h3>Basic test</h3> +<h4>Tests code location</h4> + +All tests are stored within Tests directory in git repo. + +For the purpose of this document let's assume that you're going to implement test with name MyNetworkTest. LNST requires that you name the python class with the prefix Test, therefore the class will be called TestMyNetworkTest and the file TestMyNetworkTest.py. This prefix should be omitted when you're referring it from the recipe xml. + +So, let's start with implementation. Change to the directory Tests and create file TestMyNetworkTest.py and open it with your favorite editor. + +Every class implementing an LNST test inherits from <code>TestGeneric</code> class from <code>TestsCommon</code> module: + +<pre><code>from Common.TestsCommon import TestGeneric + +class TestMyNetworkTest(TestGeneric): + ... +</code></pre> + +The only method you need to implement is the <code>run()</code> method and this is the code that will be executed whenever the test is referenced from the recipe. + +<h4>Passing the parameters to the test</h4> + +<code>TestGeneric</code> class provides set of methods to get the parameters and their values specified in the recipe. + +<ul> + <li><code>get_opt()</code></li> + <li><code>get_mopt()</code></li> + <li><code>get_multi_opt()</code></li> + <li><code>get_multi_mopt()</code></li> +</ul> + +The <code>get_opt()</code> and <code>get_multi_opt()</code> are used to get optional parameters. To make a parameter mandatory use their mopt variants, <code>get_mopt()</code> and <code>get_multi_mopt()</code>. + +For example, let's assume that your test requires a parameter containing an IP address to connect to. It's name is remote_ip. Additionally you want to let user to specify optional parameter saying how many messages the test should send. Let's name it message_count. + +<pre><code>class TestMyNetworkTest(TestGeneric): + + def do_some_stuff_with_parameters(self, remote_ip, count): + s = connect(remote_ip) + for n in range(count): + s.send_message("data%s" % n) + s.close() + + def run(self): + rip = self.get_mopt("remote_ip") + mc = self.get_opt("message_count", default=10) + + do_some_stuff_with_parameters(rip, mc) +</code></pre> + +And following is an example how to run your test from the recipe. + +<pre><code><command type="test" name="MyNetworkTest"> + <options> + <option name="remote_ip" value="192.168.100.10" /> + <option name="message_count" value="50" /> + </options> +</command> +</code></pre> + +The multi variants let you specify multi-value parameters. Let's consider following example. You'd like to specify multiple remote targets for your test. Without the multi opt variant you would have to run the test multiple times from the recipe in the background. Using it you can write following command: + +<pre><code><command type="test" value="MyNetworkTest"> + <options> + <option name="remote_target" value="192.168.100.10" /> + <option name="remote_target" value="192.168.100.20" /> + <option name="remote_target" value="192.168.100.30" /> + </options> +</command> +</code></pre> + +And you can use following code to use all of the values: + +<pre><code>class TestMyNetworkTest(TestGeneric): + + def do_some_stuff_with_target(self) + s = connect(t) + s.send_message("hello") + s.close() + + def run(self): + targets = self.get_multi_opt("remote_target) + for t in targets: + self.do_some_stuff_with_target(t) +</code></pre> + +Method <code>get_multi_mopt()</code> is the same but at least one value has to be specified. + +<h4>Reporting test result</h4> + +For what reason do we have tests if they don't tell us their result? + +The <code>TestGeneric</code> class provides two methods related to reporting the test results. + +<ul> + <li><code>set_fail([message])</code></li> + <li><code>set_pass([message])</code></li> +</ul> + +If you don't call any of these methods from your test the result will be always success (pass). + Both methods take optional parameter <code>message</code> that can be used to report the result in more detail, e.g. what was the transfer rate, how many connections have been established, etc. + +So let's enhance our example above a bit. + +<pre><code>class TestMyNetworkTest(TestGeneric): + + def do_some_stuff_with_target(self) + s = connect(t) + if not s: + return False + s.send_message("hello") + s.close() + + def run(self): + targets = self.get_multi_opt("remote_target) + for t in targets: + rc = self.do_some_stuff_with_target(t) + if not rc: + self.set_fail("Could not connect to target %s" % t) + + # if we're not reporting anything interesting, you can omit the + # following line + self.set_pass() + +</code></pre> + +<h3>Advanced topics</h3> + +<h4>Handling interrupts</h4> + +There are two approaches how to do this depending on the desired behaviour. + +<h5>Using the LNST facilities</h5> + +This approach is used if you need to block the execution of test. The <code>TestGeneric</code> class provides following two methods to support interrupt handling: + +<ul> + <li><code>set_handle_intr()</code></li> + <li><code>wait_on_interrupt()</code></li> +</ul> + +If <code>set_handle_intr()</code> method is called from the test code it simply tells the framework that the test is interested in delivering the interrupt signal. The test then can be suspended until the delivery of this signal using the <code>wait_on_interrupt()</code> method. + +So, let's assume following command sequence: + +<pre><code> +<command type="test" value="IntrExample" bg_id="1" />  +<command type="exec" value="sleep 30" />  +<command type="intr" bg_id="1" />  +<command type="wait" bg_id="1" />  +</pre></code> + +We're telling the framework that we want to run IntrExample test in the background (1), then wait for 30 seconds (2) and finally interrupt the test (3) and wait for it's exit (4). + +The python code would look like following: + +<pre><code>TestIntrExample(TestGeneric): + def run(): + self.set_handle_intr() + + ... + # parse options + ... + # spawn workers or whatever that runs in background + ... + self.wait_on_interrupt() + # we're blocked until type="intr" command is executed +</code></pre> + +<h5>Self-managed interrupt handling</h5> + +If you plan to use more complex interrupt signal handling you have to code it directly into your test code. As an example you can look at the code in Tests/TestPacketAssert.py or Tests/TCPConnect.py and TCPListen.py + +Basically you need to register a method for the interrupt signal. The following code should do it: + +<pre><code>TestIntrExample2(TestGeneric): + def _interrupt_handler(self): + self.do_whatever_needs_to_be_done_upon_signal_delivery() + + def run(self): + signal.signal(signal.SIGINT, self._interrupt_handler) +</code></pre> + <hr />

11 years, 5 months

1
0
0 / 0

[lnst trac] #41: Doc: Creating Your Own Test on Wiki

by fedora-badges

#41: Doc: Creating Your Own Test on Wiki ------------------------+------------------------------------------------- Reporter: rpazdera | Owner: somebody Type: task | Status: new Priority: major | Milestone: Push LNST as a package into Fedora Component: component1 | Version: Keywords: | Blocked By: Blocking: | ------------------------+------------------------------------------------- Add a guide for creating your own Test*.py to the wiki. It should cover the interface that LNST provides for these tests through TestGeneric class, how should the results be reported and some good-practices advice. -- Ticket URL: <https://fedorahosted.org/lnst/ticket/41> lnst <http://example.org/> My example project

11 years, 5 months

1
1
0 / 0

[PATCH] Added test writing howto to documenation.

by Jan Tluka

Signed-off-by: Jan Tluka <jtluka(a)redhat.com> --- Documentation/LNSTIntro.html | 187 +++++++++++++++++++++++++++++++++++++++++- 1 files changed, 186 insertions(+), 1 deletions(-) diff --git a/Documentation/LNSTIntro.html b/Documentation/LNSTIntro.html index 8df17b1..c83d03f 100644 --- a/Documentation/LNSTIntro.html +++ b/Documentation/LNSTIntro.html @@ -483,7 +483,192 @@ Example (peanut.xml): <hr /> -<h2>Writing a test</h2> +<h2>Writing a test for LNST</h2> + +In this chapter I'm going to guide you through the process of writing a test for the LNST framework. + +<h3>Basic test</h3> +<h4>Tests code location</h4> + +All tests are stored within Tests directory in git repo. + +For the purpose of this document let's assume that you're going to implement test with name MyNetworkTest. LNST requires that you name the python class with the prefix Test, therefore the class will be called TestMyNetworkTest and the file TestMyNetworkTest.py. This prefix should be omitted when you're referring it from the recipe xml. + +So, let's start with implementation. Change to the directory Tests and create file TestMyNetworkTest.py and open it with your favorite editor. + +Every class implementing an LNST test inherits from <code>TestGeneric</code> class from <code>TestsCommon</code> module: + +<pre><code>from Common.TestsCommon import TestGeneric + +class TestMyNetworkTest(TestGeneric): + ... +</code></pre> + +The only method you need to implement is the <code>run()</code> method and this is the code that will be executed whenever the test is referenced from the recipe. + +<h4>Passing the parameters to the test</h4> + +<code>TestGeneric</code> class provides set of methods to get the parameters and their values specified in the recipe. + +<ul> + <li><code>get_opt()</code></li> + <li><code>get_mopt()</code></li> + <li><code>get_multi_opt()</code></li> + <li><code>get_multi_mopt()</code></li> +</ul> + +The <code>get_opt()</code> and <code>get_multi_opt()</code> are used to get optional parameters. To make a parameter mandatory use their mopt variants, <code>get_mopt()</code> and <code>get_multi_mopt()</code>. + +For example, let's assume that your test requires a parameter containing an IP address to connect to. It's name is remote_ip. Additionally you want to let user to specify optional parameter saying how many messages the test should send. Let's name it message_count. + +<pre><code>class TestMyNetworkTest(TestGeneric): + + def do_some_stuff_with_parameters(self, remote_ip, count): + s = connect(remote_ip) + for n in range(count): + s.send_message("data%s" % n) + s.close() + + def run(self): + rip = self.get_mopt("remote_ip") + mc = self.get_opt("message_count", default=10) + + do_some_stuff_with_parameters(rip, mc) +</code></pre> + +And following is an example how to run your test from the recipe. + +<pre><code><command type="test" name="MyNetworkTest"> + <options> + <option name="remote_ip" value="192.168.100.10" /> + <option name="message_count" value="50" /> + </options> +</command> +</code></pre> + +The multi variants let you specify multi-value parameters. Let's consider following example. You'd like to specify multiple remote targets for your test. Without the multi opt variant you would have to run the test multiple times from the recipe in the background. Using it you can write following command: + +<pre><code><command type="test" value="MyNetworkTest"> + <options> + <option name="remote_target" value="192.168.100.10" /> + <option name="remote_target" value="192.168.100.20" /> + <option name="remote_target" value="192.168.100.30" /> + </options> +</command> +</code></pre> + +And you can use following code to use all of the values: + +<pre><code>class TestMyNetworkTest(TestGeneric): + + def do_some_stuff_with_target(self) + s = connect(t) + s.send_message("hello") + s.close() + + def run(self): + targets = self.get_multi_opt("remote_target) + for t in targets: + self.do_some_stuff_with_target(t) +</code></pre> + +Method <code>get_multi_mopt()</code> is the same but at least one value has to be specified. + +<h4>Reporting test result</h4> + +For what reason do we have tests if they don't tell us their result? + +The <code>TestGeneric</code> class provides two methods related to reporting the test results. + +<ul> + <li><code>set_fail([message])</code></li> + <li><code>set_pass([message])</code></li> +</ul> + +If you don't call any of these methods from your test the result will be always success (pass). + Both methods take optional parameter <code>message</code> that can be used to report the result in more detail, e.g. what was the transfer rate, how many connections have been established, etc. + +So let's enhance our example above a bit. + +<pre><code>class TestMyNetworkTest(TestGeneric): + + def do_some_stuff_with_target(self) + s = connect(t) + if not s: + return False + s.send_message("hello") + s.close() + + def run(self): + targets = self.get_multi_opt("remote_target) + for t in targets: + rc = self.do_some_stuff_with_target(t) + if not rc: + self.set_fail("Could not connect to target %s" % t) + + # if we're not reporting anything interesting, you can omit the + # following line + self.set_pass() + +</code></pre> + +<h3>Advanced topics</h3> + +<h4>Handling interrupts</h4> + +There are two approaches how to do this depending on the desired behaviour. + +<h5>Using the LNST facilities</h5> + +This approach is used if you need to block the execution of test. The <code>TestGeneric</code> class provides following two methods to support interrupt handling: + +<ul> + <li><code>set_handle_intr()</code></li> + <li><code>wait_on_interrupt()</code></li> +</ul> + +If <code>set_handle_intr()</code> method is called from the test code it simply tells the framework that the test is interested in delivering the interrupt signal. The test then can be suspended until the delivery of this signal using the <code>wait_on_interrupt()</code> method. + +So, let's assume following command sequence: + +<pre><code> +<command type="test" value="IntrExample" bg_id="1" />  +<command type="exec" value="sleep 30" />  +<command type="intr" bg_id="1" />  +<command type="wait" bg_id="1" />  +</pre></code> + +We're telling the framework that we want to run IntrExample test in the background (1), then wait for 30 seconds (2) and finally interrupt the test (3) and wait for it's exit (4). + +The python code would look like following: + +<pre><code>TestIntrExample(TestGeneric): + def run(): + self.set_handle_intr() + + ... + # parse options + ... + # spawn workers or whatever that runs in background + ... + self.wait_on_interrupt() + # we're blocked until type="intr" command is executed +</code></pre> + +<h5>Self-managed interrupt handling</h5> + +If you plan to use more complex interrupt signal handling you have to code it directly into your test code. As an example you can look at the code in Tests/TestPacketAssert.py or Tests/TCPConnect.py and TCPListen.py + +Basically you need to register a method for the interrupt signal. The following code should do it: + +<pre><code>TestIntrExample2(TestGeneric): + def _interrupt_handler(self): + self.do_whatever_needs_to_be_done_upon_signal_delivery() + + def run(self): + signal.signal(signal.SIGINT, self._interrupt_handler) +</code></pre> + <hr /> -- 1.7.7.6

11 years, 5 months

1
0
0 / 0

[lnst trac] #34: quick guide - vlan example

by fedora-badges

#34: quick guide - vlan example -------------------------------------+------------------------------------- Reporter: jtluka | Owner: jtluka Type: task | Status: new Priority: major | Milestone: Push LNST as a package Component: component1 | into Fedora Keywords: | Version: Blocking: | Blocked By: https://fedorahosted.org/lnst/ticket/31| -------------------------------------+------------------------------------- Two machines, one having interface put into VLAN, second having one interface in the same VLAN. -- Ticket URL: <https://fedorahosted.org/lnst/ticket/34> lnst <http://example.org/> My example project

11 years, 5 months

1
3
0 / 0

[lnst trac] #27: update documentation

by fedora-badges

#27: update documentation -------------------------+----------------------- Reporter: olichtne | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | Blocked By: Blocking: | -------------------------+----------------------- Update documentation located in directory Documentation/ in git repo. And later add it here to the wiki pages. -- Ticket URL: <https://fedorahosted.org/lnst/ticket/27> lnst <http://example.org/> My example project

11 years, 5 months

1
2
0 / 0

[lnst] Update dia files to match recent recipe syntax changes

by Jiří Pírko

commit 1afd0877d77f78822a10001785f3ee28bf4cf5b0 Author: Jan Tluka <jtluka(a)redhat.com> Date: Mon Nov 5 12:07:33 2012 +0100 Update dia files to match recent recipe syntax changes I updated also netconfig-machineconfig-NIC mapping image since it was referring to the old recipe syntax. Signed-off-by: Jan Tluka <jtluka(a)redhat.com> Documentation/machineconfig-netconfig-mapping.dia | Bin 3745 -> 3854 bytes 1 files changed, 0 insertions(+), 0 deletions(-) --- diff --git a/Documentation/machineconfig-netconfig-mapping.dia b/Documentation/machineconfig-netconfig-mapping.dia index 17eeca5..89bd78a 100644 Binary files a/Documentation/machineconfig-netconfig-mapping.dia and b/Documentation/machineconfig-netconfig-mapping.dia differ

11 years, 5 months

1
0
0 / 0

[PATCH] Update dia files to match recent recipe syntax changes

by Jan Tluka

I updated also netconfig-machineconfig-NIC mapping image since it was referring to the old recipe syntax. Signed-off-by: Jan Tluka <jtluka(a)redhat.com> --- Documentation/machineconfig-netconfig-mapping.dia | Bin 3745 -> 3854 bytes 1 files changed, 0 insertions(+), 0 deletions(-) diff --git a/Documentation/machineconfig-netconfig-mapping.dia b/Documentation/machineconfig-netconfig-mapping.dia index 17eeca5ac730ff2cd6dcd3d5444ed0bd21a7dc7c..89bd78a56b79416812d21263002fd66964f97da7 100644 GIT binary patch literal 3854 zcmV+p5ApCHiwFP!000021MOW~Z{s!=exF}qxImvg4DXk?nWDGBKD6Bhw)-5&w&G|< zu>x61CVkl7zNF;DkuAx(P>StgfN3Lz=10oseEg2cL;mpN*Sm1^=*R0IT3wA1fa8(B znn#OZwY(bt=daHn<@m=>AAVQ_-lhJxjJ>;&{={l+uCB(nNpgRAaq;x@1j6UFmqalL zg9otoFaGC+p?9GRU5r0{7>(Xmu<#Pk+}qssk|Yjh4~aiod3XNRc;?N&EaT{5wHRlm zHs$6~7{#MUFT5Imca#2%FE-U&<m#!Y``%mnv)K2(lvfS)k5X-_zW3wZYVYo&b)btR z&-Z&pO6oEHeN$#rYOM>cmY=@+iGG(gX>(&+S5ZStL6SQ!UIwdu9Q|y<>_K24F~<5~ zFeMcfRG^n<(j0C!EL=D&Ts$mXu)e;J;w1KhWFK-CMWOGlGSnn~@Z008=U%8ytg2fb zdT|pZNpzt7H(t1|(}C>vtG6}v++`drsvS31qNJ9mV3FKjf9>gUWwk%|RQqGF4rZZW z)cRnRSgZcoPW8LrPRicfk9V|&thUnOVIh6yv*yFY@*!CG>jP$%FH=&}?WWkpp{KrE zuI_`$ZtV=#DMaW!`|+mwpSQ#GX!8Yc7-!_oli=~?>diBWX8-l)$)>aaPQ2B^ix;Dh zqrd#G$@q;38IOX+)%c$<|Fm}dr)$$hxc9j3qgR`v3TUdOlaCN6!FC_SK8=*2%x1eF zvF?YrT891(5CTk083j~kuoAa~P0S-XVD~#^%4j?l3b}GSn&K~ios90h`E9WBOVmY$ zOP29_v`UIV&Hd4hcNc`ux^3QSJsz!-XJb23OV8}H|M0^{KMCgE$DgBc@z&6rx8v3i zmbZm1*)pg8o?!lmb_30uWfRkEgO+Ek3Rw$bHz2JCma99z_>1*d4|ki#Sres@kD9s3 zW7?!$N7*)o9PqyEX2wfzh|2KVeGWKBU4Qz?Qxt#E%=Odgk6;lb(UYddfBjOxVdxN> z@3Yvxu`mLdmX8wz6yy}QABgwJteDO;9u+B`WEyYEIKYI8i2zulF8FtT;_ajF^4cPp zC+#u((7(H$NAb#!hk2+eV5-lmBLL1ZRofrl5wU>Sb|4ubIYdP|gj9NLINV7H&<>HJ zj*y1J9^xXKsiL-~p-33k0?NO2Xc1A}Mo-rTuQ&RL-qNR+j;#AI<y37iybFW->)R*} z{?_BY7g`GRs=ze$8p+Tz)cRp&;$pvRAhtj7wA0Ag%J@PxQ)ntwfDJRgZ15yd2$}Ka z6`!+C_{EC&pl)uWoOiTysa~#BSM@dXLDjr3n)5E*rX7Wvxw&d?1HG@D8<}f6&>{g{ zQ$n|aE0fWO*tuG;7mMk}uWEJ$b(N%U&TctjeSq<Pj=sJjJh&k|aya5GqPzktLI5eu zCsYSwMDT8rQ33IlP@hJnDJoYQb!t?oX$1pPb#6tO^zFIxB?7oW0+XB^RW@+z#P<k5 zWfOQ7#S1^K)8(xoMpQwBIKthagO&bruWLp8H#akH=5>RsQml0}>%r(h&k^l35Vc4N zJaa~>2Bid^`Jz-ZqXfht(yid#eX~sK)X+rDRMCzu@{?Osp^Xj<n@#kQ1%=eEH6<#k zjZSLUfFiBb(5Tx&7b~XPnyDRVxo$eFoDS)<GWFEl;|dg1wT5cQk=ecdH<aC_6|*X> z<b(r65RpSFD+3Cp2F-+(%wAb`Z9_v{WvS<FWtC7)RykSKT~=|MvMTjVH7p%upoH*@ z4iIEa^8xJ62k$7VuoG3sBC5(v+G(nj(^TyUQdlEM3=k*UnsoR#96`Q-;!H1Pmzp0j zKUIEo+;|k+SYgeM8_y=*Y)F>U#zZCM*}@d6LmtLx?-P|TcmxOr8BJBBq(b9U)d_$2 ziAo4Be}k9wmrF!1@o$&x*LR<}the6p4CgN^tk}(89{2oZL()^0NKa_;nMeRRVPpu> zOYsDtTry%vkDwGEqfYqmLV84#-sem4`SSCx`gccq??`%OR_sXcG)b>`76Cy^q(`tI zMtNZ<#So;2MT*CT#!E@hTvNapq@@4l$ksYsZ#lB)ef2Q}LTHi9m3DVMd=N=HtavV+ z8fZ2#&)X!b}(&bUH!sD;7J(jvP%G_n=CrSowV6UhgO+^B&gLc^uAf%;NQ7)Cm; z^{?m6R(k84**SCXODYkzIq@%$NONigLIckH;}lggjhZ^UX$1k0b#6toxqoY&cWWw- za`GR-o13m#lqWIyk8G~9=Ef~B;A~J%*q}m=GfqHQVSO#TJLfyj|3f#&bu9D$rAF;0 zxxSGF0Ek*#0YE4>_C$vy$qlL&P8mtQwt}B7Njic&l0^XJ2JHy)s0s4*fofemPc-AL z3*GqTucKSdlN*yyqAZ>qZU1~VE?iAiSbLA_4-m8R7E9`|M-a`JOmQ~AYphp19qq96 zJr)*J>T5we;SWC-hm=_tBmp+@o12Gww|Tg73wHBxXEhJUtq`67k`Ot8KoJOu>Ywoh z5Hban(f}IDqa2xidITek4e;*XT9@m+y=Q<4L9wEga!N?&$;Ntb^9e&*@?)WuKI4#{ z?c00^Iq9-FP}$4D8m|VAbJ}1}PgQcu@4?D1A{WtlZ$_$(5UB~%%0@?@eQwUEksvYo z)sP~>r)F*rQ<Gl}1y?PRjeNcKSBtbqt@>HM1b_mBAgApbriYsO{cd}Tc3EvwsqW~t z7st_4`A&NncdYt4^jFIqh3pXs>k6?;Qf(26gO>wg5s~?@i0;`!!H3aHOa=2FCi~mE z?lh@nYs03FE-g4Z!`cCi@@G)>>*$mdJP~F<<=8m79^HgNmV%Q09lf}p6{`cJ<|F6l z=jP|Ci=U%+@^jVM&oRJSN~W(WIHrC2xkkcR8G(+G7S2<x*cD}TVv;h6LVY`WSx3u5 z2?Pk@(mDEhIXcB%9G&;<=w%y5cHUJTV}O|1>Kt;2P>+883d9*hXo>~k0<(0>Y}6Wg z$c@$i^pjtr)lIM*h5n--y1mth*;~ELK--|Xz13~+t=^QcP*=Vp1Z1RPtf9|SATl5X zn5HWoeQ3lKSEBZ~L$cK$*$EIE#`@hc)^LnfW}=R<PT(|%8XRV2mu{>LlTC7xwx>Cm z3`yG~RBVcs$yR0)L;+@}G~xVxm`qoGGEe#J`(-lKh0Q(vK>hf}oBQdPqraoQWgY2H z)*xSp7bOMmZ=cuKn<`9^i&6~S9RrUm5y<#MN#(O>wHR+cmwht2PlJk!+|709J^Jg{ zTW{}f9@9nnAMrR}*+s540KkXzZtlx)8>bIH_g}~$Zr1-OX8jMHO>$uNaem_?pC8%L zB-ReOAXdgtvw~nk03k~Dzm6e8!$43f)$|2h|K0`Lop13?&~%xhI;uXW1zMO|VKr*T zbPSMY7TG_mX*2_-EmNAv!0cDh5xMTNEK41&w<e1Ml1pxse1Jt+Dxb-T)!8n}GApG{ zVXah4xngChIVK>TV;n}U7%&KECRQ?J<g|*@DhIVniIqC3a#m7>+mk8`P&f#s8L7em zVaiaNkt)0^ax<yItiU;`;-pHCQbkyCYyqH==A6?ZVvr3Q<Y^GHxss?8wo@zLgjy*x zR3}%C=_Pnc=JBERc$ik?9hYVuTcc9xsMJxZqf$quj!L^ysg-@xF$U=#`~9=10U~C5 z>*)rQGDn||J`b!>-ZM_eoG1Fu%>O&^<C4TG0xhjwP;7$G0E_>SG~2XLO=wCIDh#DT zh*1j8FzWEm#sB+yFS)92SNF>y0Z3Yo94v>@ZQQGiX;{R%4Hwy)!E0k5>nbCJ1uZH0 zYs1%f1zBB{d0njm_H(<cbFbP1)p#$+hIeXY(WxQe19-InQV_F?3Q~lt)T<HV23_d? z59QUneJyZTZsH1c(5D$mcX(!E?@aR|&({6M&as_im&Y6gTZ%aZ$7YSKLYNH^d2Hac zH>A-=dTBD>unR$42y!R{DX~=-h#YAkQoMIl=lmpMWqmc#Qo^hu>Yw&fq>s=XGph}F zYPMLCgqv6Z5<yNaN9iuhyDZ34x`{@&(K^Yh%k7`JlP?rUQF8CC*H`1O<2N;|{AA%j z2J<(GJ-OR&^N;k+rzrk%HP*kN@!^c8;u5z{-eM7JpW8icbn}4=%MHOb8j?Q&aGYz$ zOJ363$CTdN`%>HpHT(!w$S7`ba`{R}p07l#tn8=6ypighGgNoq)f5c_smv1K7i>=4 z8em7$hqjb1GgL>_XLXu2VU}o(u?Zh24KqVyn>5T9Y?p@VXsr&d6&tFfwR6gCAXai4 z2nAe0Gb14pBDDWkAR3RRc!F!ZDNz8KYkgY~N&C-nu-4%t&T^0lzs+-C++{hO;sMq~ zSn_azn3xDNaXOHPbB)J=di8Lg;!ED$;p%y~oem$dhl@O<BF@84(!-^#F<eO8eGF~j z;W)#?8qdsQNQ_O+q8iA*?R2-Ee<QP<91-b&iWyaGh;wc@&rYq!LO`OO-5pwglJ2c+ z4d5_69-`v_+Q7Y8hG)i4<K9f*i3Ci^ffTx({?_wvrMoG&?oGuI<2RRrIiEhs)MIL8 zVKgz@WKpvP1tt*ne<0@zo;E$g5T9=GiR^^$-YI?)Guq|m>fS1z)no~^vP7J4AXWNW z4<o_)pDua9BRV9(Oij1=gm=Ps^!82ATe-P9dOL%(V8RDU3oecVDYnF@TuEdE98yE< zv0wmc3dpztoKg%3W@eQ>?R?g6oiNZ^huv|;?l|Lf2|n$tc*j7So$+MB2gvr>!XYij zrrXPIxkgT!eG}5G)K;A`JE?4+Rtd|Lc0Tnn-S3BFTYvX?=pzS8VyTg!z?@EB)|pVi z6r`dZa$%Bk%^nsOr0E9zYUkziez`Pq#+9YE9o&hTnjKzSn4w&mfn55xCcvS#x5KBf zR!AjxYVE+M*6wcY#Os_|OG*Mj>!;RMvlz3(Vm#XwxOWyaTMlD|F`91I(g=ato>1L@ z#rAqwSdi)V;L0-6RHo_f0D*1#M)T{09Dz9k>w~~}7XlMq2`sw~y=OoE^dY;@|CX_L Q_vyp`0o!0)9Zul@0I@Qa;{X5v literal 3745 zcmV;S4qoveiwFP!000021MOYea^p4@eebVODOLTXhOsYJ+^K9`^N?hwYBJ9*N}?rB zXwpT|cDo<u+Xo=!MG_a01Zhcus<M!#Z~*Gwg9F^l%kO{qdK-=&{A3-((bX6MI3D@Y zJYEFR@@o8_KfipE;~zeM_<j+1m-?S&;@yt)H=?yUx*D(2^zQQF;_>kjgimWPjS~<C z_h9W`{Lc$R??PX6G5-8vG<w^>!b?4KZgbX4(<GSPr~WANZvCtA%$xtUOyc`!G0v~r zTsM!yI2k>7;nn!No9r{b*fevo)lNm*ciz&UCBFApdDBpTlxoxTouBMBdwUnJ1AR&Q zbhmd&Njv7>Z?4%~wbmC!%g^8aNWaUwv^nwGR#8VwLDE|<Sq9NQj=ncxej_lD7-M}i zn34(#D$w&iX%06V7A_nXE*TasSYO}8Nt$>;x(_*v<Iwk_95qeu{q{KPxff~^s~T2^ zQQQP+8rSsy#tYYn3?M)K;%!YmcbNo>YRBEWqNJ6_V3Dq_zxH&y^46bvYW*Qt2eZ&G z>U|KU)|!8^)BNtQld<>f*E?E6-dgGOu#i6US@Y>(c^@qNb&Z*AUsKZ3YIE5|-Cf_k z?$8^PpW2zMGl<Z8@{>*TKfO-Vqs<SzVVsdSPlJc&qc`^?p8eOKr<=k4JN2T4mn=q~ zMt}NW)A1V-G9CqstMNbK_TAbYpKeVP;oj}Ki(hPtDxj&BPCh}P1lzq4`!rI9GMnv! zBzhcPv<&?nAOx70G76~3VKwWw#7)gTsWJSWYsz>$Qwm$x?TCs${dGFJ_2#P}@=N4J zg-@0dd>o}kpyvGO#=8x|C*3zMT8~HT^vM{H)Y>!u?mztS!B2y^_vxoNT)egP=KWat z!E#mDlUM50KNQ^l&~BjHcG<)>+n{YzR)wyGup5vT1k32wFaBZu=>B$dI}b!DB&23; z@{o0D*HK=(LTbD(KbaF#d!|BNnTim=GE?9Xp+1=^2hudf7{XJk5h>1)B@`T;09XB< z)6~y#bQ3H`zxfY-=qPI#$|^HbM_I=}Sw@T9Z2>nVF<d7+_i1e3MzFR^Hi3Y(UoGtM zSTU33NZK5sVpFWN<eDG~FvA_7i%F`M%9@bb4xN1r(`n?V^Nh|uF4L*Lcyn&yKLm3> z`)%}3wA0AulXu8ZS7jI6t)AA`n<mU97o`}uI|d$CB9QTilE!DTUPWxamwz+9OSN&X zFSbsuL+`;~znpq|c5|C9%KwPR+l^gpwFUtAke%K7F-m8aN*+3VcB!3T_NSL^o@&#N z!r7(y{L%(`e~vkjLE6C;O)>{gGi~6?rkc9Rrg~B<o^Tp(!R$^tRnt!My}U5I-oM#< zH+p{KBcFHJkzB=(*9GB$PP?D`(`mculUSKP5fE%b03k}M{-@9k4eNy{m1_EoO%*2U zl;%*!((l01WrpgQ`Y4#%7OPP!tcC%~b{(KuIrdL$&v2YEgr-;k&hv$<+2c4RX8XfW zHya&c<wnO)M0ePB$2rnnsRcW}J59d(DgOF~?%;;*m=(ICW(A`yMk*=$XFH8%!1P2c z%{~axvvNmdKlE?4o=+k_8DgLrTo&N23U5<D)Z35b9T5vCXOC_a-NM8jbnz@s7JgDc zP6*J3+YnWnY&gQ5K@V7)-Q4U_O`mJCW|<w`Wem6C*97p1o&tthn;9?&XudSdk&#=O zxs_S1R4K7iCsfW!s0d3!Md(#L0~8KIX&Me2IAXFOjaI?>katCIpjNDm*2xtoS9+E! z(u#Kr0F655oDQ)J*`Pt5twT0P5(y%mVsVP4Qn8d7s*^0o6!n|OQKWs|gyjod^7(J0 zl_s~1A*XS+r80W`>(#h`4GJ2zMWo6RsUuQHq>e}(k#-|e1T6&u@kFnTh6n-T2>}AK z=?0UYSYn{#&v%LP?U|>e&J*1>^S=dt@>>x31-oYmSxVMYY=Y1L$<9au#3j{~rX-=l zkQ#&-W#9~Vc{1DocAX8W%~1ERLjsWOI#PQb(w@d@n$xg|b(=8qjlpYUAL}Y3gath* z`D???yJ&IkB}x2Pg^sZWfa}nYmUX*z%m&Z_yMk<Zr^XhY8Uj9mR|_Bo!C7RFaFuyA zLfoJW{okRydUvb^?#j)=Le=^-BS>hDVuA=>@7a3X*g5v!!?E)-Z=O*)<e8;E{PZzS z{?d;B<LLKb5v1{>pN#(XbJ6<5O8Pa^wu`ZGNCi2?y%T`OqawqTOyf-%2Ut(<69KS9 zUGQ)H)T>{wEP{F3f85R5O+75|X0|`@+c;SNfj0)o7NY8)S3*6xHHo@Ce^5tAvn;u< z3A*hsS6V(Na$g(Wdt2V=NFEfax_jB0x#=uqr;bh-++DBYB>1LR@?K~ukXZ$$x!3Fl z^bEDWpP2$ge%FdO);7SbWWqDOmN8tY02^k4+2Bc_5Hb_Y3qEI3VYeaXHpHqn#460y z?Ta1vzSx$uZk1w&Sbe>YBF-x?qbzlmPbd&{e`VOPphE%km2jU%r5P$$8g*)PsObd* zQg!Y{nfUE_@FfzsKm?QRR4^O3hm<8j04kfnrD<qQ6VaMO2T@d*i&m&tXWq=~23Mt7 z4^gePMN76xqNNJr7CC|E-bmG;oWOHuluG8DfEYx&7o2k3u@_}(=KxjIOc(7aBR^fC z3UyR7aW+v%7Bo`3-jwL1HcF{o2a42EL!)jBU96c7R!!|d%av2TcB)fqW%{YP#}#O( zY8BOxB=>eL?TIU4Rb0sl2Z$gdhtyUE6iN-6ODmagTXyY3LuF-Y<ZXqOP)=AmVP!#B zNt?ndb4@iYALO8f@SG12WK0tRltjvtl~vfus$-E=WhU)Z)yb)<mJF$^F(d|v6Kzg< z1vnf-K7-<1G3AGvAhA4Ef^_6~6y#W8&5j(;X35#Kn6H(5eaiFv6slJ}jM3i1mCtwt z2nHF=bfi?mr0**U=_!RPA-wz*Uecd05xvB}Ub0_Y@virZVpdqOi(;NtwL*+6v7XTE zGm!vt!pIP;m*ELOxn#t!9>EztMjVn8V?Cl-@5`n5a{1*K{r`^j-jVgntk|*MIh6v! z*b?axEKKo0fuR&bkRBEp9v2!fBRz9$9twh#^q-b&ZNP`6C5r*d{|KQN<4U_bVw6bA z&$j%JoN<Nd$(R2racE*|?Uu#lC?;KsPc>M&Q3FSWhRY&?`cO+4Mmp#GALh+gM(do} zIdkusm6+NL{tG0sXKTc6Vd`F^|2RXHOrvJbF0v>8AnV+VX7PV(gLj#gN0|Tsp{exu zH%I`$HnXj{aSIGM8<Z0^sF35F6A)I|l&*q`qmxYmfG)~)EGYn`M(x5}f0G;l%q`{s z5Xy}`(IH84gQ|s7PLeOZ;HOKHjv$XD4WQhh9YG#7K~~oVtgj5H*OTR?0V|3F_M3rV zr9?fIdf6k0W=y6y8(<sj1y8SbShkOa1(o_(=(P_&rC1zNCNoF^Y}Ris4)<<xxN-}2 zak#UJ!&#}?PX&;K$O#0BKuG$3D~ARYG6R&-02<1p9GQAOf)U0B*t@qj<imFF8DK(C ztSF_N64E)?c-U?}VMt4UEI1U5cgbZt^4)w0Iq6a)sBClafUUvf3>&m6eRhDpvQpcg zXwx*W8SB5;VTSZc8zp5^N;S8zi2@X!R#oPYVLFZc^wyiN0<EUAce8$6rc?bL^QR!X ziASq=o#riWDX{TqtKlS$(>rgyz8ZfWziB}?zVIJ{`E%!e?c<}pWl;9HTRp9>jVYkA zD^`!*Vv%Sj*v&=FzHm_kTZ4)ZK;6y-8^3@W$cv);=!*OdFHj39z)90%dSgIoA-$R@ za(?3@pC4HrJzL4X#LgoQrUJ-BOI|s|EAVnO45Tuz^?b(W)V<f!(RAHDLYbjDsy?e{ z7znaNYm8;j;}1k@%)D7s&<(9+*wnqQ*wNYnv{r1Wj@Hg;bCg(lNP$qTm0*@=h!E-j zc~p(Z6f{9q#WmiPC;(N4F9ngb|E*DL13u!H7E82MJe_g((&AHmYJm`29?qFCbuxzX zaE>xO^z7lt918$>cZWOB!>tVXh&^0vLw0#Rg7ffq^l)m+!?DEO=g<aoxXAIa#>-+4 z!W08wYAFA<GTg)b8$qp5h{z^X%&1~R1UEU)A63FaK%$-9J*jk(?#*nuHzT<F1lnK% zhdG{^KaG1cYz~EzLn(AC<2}s3m6pr$)xD`0V*ch*Fz3_9?bBtuiQI})6F>;%=7oI( zqW-fmpYgQm5r+8m6`x4Vx!Y58dy172?Q(N<yNc%(EU}VgPB@VHE*nLH^&c*I#>09^ zf|;7W;xhrE3z;~2tERVdb9MA~OldnM5A@VM&O>m;<2<Dg^VnJiN=uB&l|)9sAw{Je zf>Jrn02w!cQ;JOyJ*G7P9ip0)y#c!%c9+9`B0213%<@|h`9;+7nz4Q$vFyDyUIA>< z=Q!VTv9e(t#3w~;qH&NSJbNx%QZ^+fUma1Cs;3Y^?T`&;U;EJ_8&8W-Rz-(*gg}#S z>4|NAx7(W+h?Zl0d87Pp!>{uw#vPl!4*h7kMITk~s&5CeOHgeQiXXnM(E)5*2GBiI zDEKZa(GX;}pL;zjaQYTLPN4-K*T!t#(kZD_Jv%v)${=C$E<oetf}30<DU}fYJ9*(S zt0KgFJ3{Qd{2aVobn$ZXPF{|>dbx?hW+mA%lpOcy<<xkOGF4tB7kXL10VUe$DPT}R z+Ow0Fjk3HNE!CU^xpVR}b8<pEcsYKrxg1;Yaw<%0ltKnozg|wYFgN9AiG<X+xn84k zQ~aC?BKmjp!eLgFsg;O0FF!jk@1of8d(GvfvzKFl1>;%G9FA$9Zmy9qR;E$}Mii?l z6+lr&C*}o#MD@KeFCA!kO$!7F;?g<#nK`=b;^?xgqvyw=_v9y^Kja7cpJn3Re*W-( Lb?f`B(bWI|1=>LO -- 1.7.7.6

11 years, 5 months

1
0
0 / 0

LNST tools packages

by Radek Pazdera

Hi! I was working on the patches with the test modules/tools transferring and caching while it occurred to me that the tool .tar.gz packages that we plan to do are not such a good idea. The current implementation requires the tools to be packaged in an archive. But that is far from convenient when it comes to developing new tests. The users would have to recreate the archive each time they change something. That would be really tedious thing to do. On top of that there would certainly be some problems with including those archives in Fedora packages. LNST could do this automatically with ease. Creating the archive is straight-forward, the only problem is keeping track of the hashes. It would be really inefficient to recreate all the archives each time nettestctl is executed just to compute their hashes. I'm not really sure how to do it yet. Maybe check modify times of all the files? Or we could invent some clever way of computing hashes of directories! That could work ... We could cache the dir hashes in lets say ~/.lnst/.resources or something or maybe it won't be necessary to cache them at all ... What is your opinion this? Cheers Radek

11 years, 5 months

2
2
0 / 0

[lnst] Update the documentation

by Jiří Pírko

commit 05a866d84083cd52bf729e3e6b1037fd7e3a0639 Author: Jan Tluka <jtluka(a)redhat.com> Date: Fri Nov 2 20:51:22 2012 +0100 Update the documentation This is an update of the project documentation to reflect the many changes in the last few months. Signed-off-by: Jan Tluka <jtluka(a)redhat.com> Documentation/LNSTIntro.html | 317 ++++++++++++++++-------------------------- 1 files changed, 123 insertions(+), 194 deletions(-) --- diff --git a/Documentation/LNSTIntro.html b/Documentation/LNSTIntro.html index baea586..8df17b1 100644 --- a/Documentation/LNSTIntro.html +++ b/Documentation/LNSTIntro.html @@ -13,14 +13,13 @@ </head> <body> -<h1>LNST Project</h1> +<h1>Linux Network Stack Test - LNST Project</h1> <h2>About</h2> -LNST is an automated testing framework focused on the Linux network stack -testing. It supports bonding, vlan, bridging and macvlan. +LNST is an automated testing framework focused on the Linux network stack testing. It supports bonding, vlan, bridging and macvlan. <h3>People</h3> <ul> @@ -29,12 +28,14 @@ testing. It supports bonding, vlan, bridging and macvlan. quality engineer</li> <li>Jan Tluka (jtluka) – contributor, test development, Beaker integration, quality engineer</li> - <li>Radek Pazdera - contributor, framework infrastructure implementation, test development, quality engineer + <li>Radek Pazdera (rpazdera) - contributor, framework infrastructure implementation, test development, quality engineer + <li>Ondrej Lichtner (olichtne) - contributor, framework infrastructure implementation, quality engineer </ul> <h3>Communication channels</h3> <ul> + <li>Project web page on <a>https://fedorahosted.org/lnst/</a> <li>We are on irc: #lnst @ freenode (irc://irc.freenode.net#lnst)</li> <li>The development mailing list: <a href="https://fedorahosted.org/mailman/listinfo/lnst-developers">https://fedorahosted.org/mailman/listinfo/lnst-developers</a></li> </ul> @@ -43,8 +44,7 @@ testing. It supports bonding, vlan, bridging and macvlan. <h3>Goals</h3> <ul> <li>QE: extend our current network code coverage in Tier tests</li> - <li>Devel: create a tool/test environment to easily catch regressions in - network stack during development</li> + <li>Devel: create a tool/test environment to easily catch regressions in network stack during development</li> </ul> <h3>Target audience</h3> @@ -55,8 +55,7 @@ testing. It supports bonding, vlan, bridging and macvlan. <h3>Topology</h3> -In the following picture you can see an example of the network topology -along with the roles and communication paths. There are 3 basic entities, +In the following picture you can see an example of the network topology along with the roles and communication paths. There are 3 basic entities, <ul> <li>controller </li> <li>test machines</li> @@ -72,17 +71,11 @@ width="712" height="279" /> -In the picture you can see two network connections drawn in different -colors. +In the picture you can see two network connections drawn in different colors. -The green one is the controller path and is used to setup -network interfaces on machine1 and machine2 through the controller -interfaces (eth3 on both test machines). The controller -path is also used to do setup of the test switch and live changes on -it such as vlan and bonding configuration, port disconnection, etc. +The green one is the controller path and is used to setup network interfaces on machine1 and machine2 through the controller interfaces (eth3 on both test machines). The controller path is also used to do setup of the test switch and live changes on it such as vlan and bonding configuration, port disconnection, etc. -The red one is the test path and is used for network -traffic generated in tests executed on test machines. +The red one is the test path and is used for network traffic generated in tests executed on test machines. <hr /> @@ -103,63 +96,27 @@ traffic generated in tests executed on test machines. <h2>Source code structure</h2> +Please note, that not every file is listed. + <pre>[./] - netconfig.py (tool to configure network interfaces based on xml description) nettestctl.py (tool to control remote machines/execute tests) nettestslave.py (app that runs on remote machine and accepts commands from controller (nettestctl.py)) - switchconfig.py - swswitch.py [./Common] (common code for the framework) - Daemon.py - ExecCmd.py - LoggingServer.py - Logs.py - ProcessManager.py - ShellProcess.py - SlaveUtils.py - SshUtils.py - TestsCommon.py - Utils.py - XmlPreprocessor.py - XmlRpc.py - -[./example_recipes] (inspiration for test setups – netconfigs, machineconfigs, recipes) + +[./recipes] (inspiration for test setups – netconfigs, machineconfigs, recipes) [./NetConfig] (network configuration class implementation) - NetConfigCommon.py - NetConfigDevice.py - NetConfigDevNames.py - NetConfigParse.py (netconfig xml parser) - NetConfig.py [./NetTest] (test execution class implementation) - NetTestCommand.py - NetTestController.py - NetTestParse.py - NetTestParse.pyc - NetTestResultSerializer.py - NetTestSlave.py - -[./Switch] (network switch configuration) - SwitchConfigParse.py - SwitchCtl.py - SwitchDriversCommon.py + +[./Switch] (network switch configuration implementation) [./Tests] (implementation of network tests) - TestDummyFailing.py - TestIcmp6Ping.py - TestIcmpPing.py - TestIperf.py - TestMulticast.py - TestNetCat.py - TestPktCounter.py - TestPktgenTx.py - -[./test_tools] (non-python testing tools and scripts) - multicast/ + +[./test_tools] (place to keep non-python testing tools and scripts) </pre> @@ -167,22 +124,16 @@ traffic generated in tests executed on test machines. <h2>Setting up the test environmnent</h2> -<h3>Remote connection setup</h3> +<h3>Controller-Slave connection setup</h3> -Every test machine has to be configured to allow remote SSH connection. This -can be achieved either using keys or specifying root password in XML files -(described below). It's mandatory to have a dedicated control network interface -for the SSH connection that is used to setup network on additional network -interfaces and execute tests. It is also important to separate "controller -path" and "test path" infrastructure, e.g. using two switches. + +It's mandatory to have a dedicated controller network interface on all of the test machines for both the XML-RPC connection that is used to setup network interfaces for testing and for the test execution itself. By default the xml-rpc client listens on port 9999 so if you use firewall of any sort this port needs to be open. If you want to run the tests using the "remote execution" (see chapter The Workflow - running LNST at the end of this document) you also need to have SSH daemon running on all of the test machines. It is also important to separate "controller path" and "test path" infrastructure, e.g. using two switches. <h3>Required packages</h3> -Basically you need to have python installed. If you use RHEL5 on a machine -you need to install additional package python-ctypes from EPEL -repository on it. +Basically you need to have python installed. If you use RHEL5 on a machine you need to install additional package python-ctypes from EPEL repository on it. <ul> <li><a href="http://fedoraproject.org/wiki/EPEL">http://fedoraproject.org/wiki/EPEL</a></li> @@ -193,30 +144,40 @@ repository on it. install python-ctypes</li> </ul> +<h3>Optional packages</h3> + +It is recommended to install following packages. Either optional framework features rely on them or the LNST tests require them to do their work. +<ul> + <li>tcpdump</li> + <li>nc (netcat)</li> + <li>iperf</li> + <li>iptables</li> +</ul> + <hr /> <h2>LNST Recipes</h2> -The LNST recipes contains all information to do a test run. +The LNST recipe contains all information to do a test run. It consists of: <ul> - <li>machineconfigs</li> - <li>netconfigs</li> - <li>command sequences</li> + <li>machineconfigs - to define the set of machines under testing</li> + <li>netconfigs - to define how the network interfaces should be configured</li> + <li>command sequences - to define all test sub-tasks</li> </ul> The following XML code is an example of the LNST recipe: <pre><nettestrecipe> <machines> <machine id="1"> - <netmachineconfig source="example_recipes/machine_configs/config-f14peanut.xml"/> - <netconfig source="example_recipes/net_configs/netconfig1.xml"/> + <machineconfig source="recipes/team/machineconfig-test1.xml"/> + <netconfig source="recipes/team/netconfig-simple.xml"/> </machine> <machine id="2"> - <netmachineconfig source="my_recipes/config-f15.xml"/> - <netconfig source="my_recipes/netconfig2.xml"/> + <machineconfig source="recipes/team/machineconfig-test2.xml"/> + <netconfig source="recipes/team/netconfig-team_ab_lw_001.xml"/> </machine> </machines> @@ -224,7 +185,7 @@ repository on it. <command type="exec" value="sleep 4"/> <command type="test" machine_id="1" value="IcmpPing" timeout="30"> <options> - <option type="recipe_eval" name="addr" value="['machines'][2]['netconfig'][1]['addresses'][0]"/> + <option name="addr" value="{ip(2,testip)}"/> <option name="count" value="40"/> <option name="interval" value="0.2"/> <option name="limit_rate" value="95"/> @@ -235,48 +196,40 @@ repository on it. -Every test machine's network setup is defined by two configuration XML -snippets – MachineConfig describing the machine's real hardware (available -NICs) and NetConfig describing configuration of these devices (IP addresses, -bonding setup, bridging, vlans, etc.) +Every test machine's network setup is defined by two configuration XML snippets – MachineConfig describing the machine's physical hardware (available NICs) and NetConfig describing configuration of these devices (IP addresses, bonding setup, bridging, vlans, etc.) <h3>MachineConfig</h3> The MachineConfig <ul> - <li>describes test machine's control interface and login information (for - root access) - info tag</li> - <li>describes available network interfaces of a test machine – - netdevice tags</li> + <li>describes test machine's control interface and root login information (for remote execution) - info tag</li> + <li>describes available network interfaces of a test machine – netdevice tags</li> </ul> -Example (example_recipes/machine_configs/config-f14peanut.xml): +Example: -<pre><netmachineconfig> +<pre><machineconfig> <info hostname="10.34.37.141" rootpass="aaa"/> - <netdevice type="eth" phys_id="1" hwaddr="00:E0:4C:14:2E:5D"/> - <netdevice type="eth" phys_id="2" hwaddr="00:30:4F:7F:FD:30"/> -</netmachineconfig></pre> + <netdevices> + <netdevice type="eth" network="testnet" phys_id="1" hwaddr="00:E0:4C:14:2E:5D"/> + <netdevice type="eth" network="testnet" phys_id="2" hwaddr="00:30:4F:7F:FD:30"/> + </netdevices> +</machineconfig></pre> -Test machine with this configuration will be accessible via IP address -10.34.37.141 using root password 'aaa' (rootpass). Two -interfaces are made available for testing - one with MAC address -00:E0:4C:14:2E:5D (hwaddr) exported as physical device '1' -(phys_id) and second with MAC address 00:30:4F:7F:FD:30 -exported as physical device '2' in LNST framework. +Test machine with this configuration will be accessible via IP address 10.34.37.141 using root password 'aaa' (rootpass). Two interfaces are made available for testing - one with MAC address 00:E0:4C:14:2E:5D (hwaddr) exported as physical device '1' (phys_id) and second with MAC address 00:30:4F:7F:FD:30 exported as physical device '2' in LNST framework. <h3>NetConfig</h3> -Example (example_recipes/net_configs/netconfig1.xml): +Example: <pre><netconfig> - <netdevice id="1" type="eth" phys_id="1"/> - <netdevice id="2" type="eth" phys_id="2"/> - <netdevice id="3" type="bond"> + <interface id="1" type="eth" phys_id="1"/> + <interface id="2" type="eth" phys_id="2"/> + <interface id="testifc1" type="bond"> <options> <option name="mode" value="1"/> <option name="miimon" value="100"/> @@ -289,19 +242,15 @@ exported as physical device '2' in LNST framework. <addresses> <address value="192.168.101.1/24"/> </addresses> - </netdevice> + </interface> </netconfig></pre> This configuration snippet uses two physical devices -(phys_id="1" and phys_id="2") defined in the -previous MachineConfig. It also defines third network device (netdevice -id="3") as bond device and adds the two physical -device as its slaves. Further options are defined in -options element and IP address of the bond interface is -defined in addresses element. +(phys_id="1" and phys_id="2") defined in the previous MachineConfig. It also defines third network device (netdevice id="3") as bond device and adds the two physical device as its slaves. Further options are defined in options element and IP address of the bond interface is defined in addresses element. +Please note that you can use strings instead of just numbers for interface identification. This is very helpful when you're referring these interfaces in your command sequences. More on this in following chapter. <h3>Mapping of physical interfaces inside LNST recipes</h3> @@ -316,13 +265,17 @@ src="machineconfig-netconfig-mapping.png" width="793" height="318" /> <h3>Command sequences</h3> -Command sequence in a LNST recipe is a list of commands that is executed -on test machines or controller. +Command sequence in a LNST recipe is a list of commands that is executed on test machines or controller. -Tasks can be of type: +<h4>Commands</h4> + +Commands can be of type: <ul> - <li>exec or</li> - <li>test (can be run on test machines only)</li> + <li>type="exec" or</li> + <li>type="test"(can be run on test machines only)</li> + <li>type="intr" to interrupt (SIG_INT) commands running in background</li> + <li>type="kill" to kill (SIG_KILL) commands running in background</li> + <li>type="wait" to wait for completion of a command running in background</li> </ul> The exec command is anything that you can enter on a @@ -334,12 +287,7 @@ command line. E.g. -The test command is an implemented test. The code of the -test is present in Tests/TestIcmpPing.py in the example below. -You can pass variables to a test using option tag. The options -value can be obtained using get_opt() method. For further -details see section Writing tests or look at code examples -under Tests directory. +The test command is an implemented test. The code of the test in the example below is present in Tests/TestIcmpPing.py. You can pass variables to a test using the option tag. The option value can be obtained using get_opt(),get_mopt() methods. For further details see section Writing tests or look at code examples under Tests directory. @@ -360,27 +308,41 @@ under Tests directory. There are two commands in this example. -First one would execute command sleep on the controller machine because -attribute machine_id is not supplied (default behavior). The -machine_id attributes defines on which of the test machines -command is run. It's value matches one of the machine ids defined in -<machine> tag in LNST recipe. +First one would execute command sleep on the controller machine because attribute machine_id is not supplied (default behavior). The machine_id attribute defines on which of the test machines command should run. It's value matches one of the machine ids defined in <machine> tag in LNST recipe. -The second command would start IcmpPing test from the -LNST library on the first (id=1) test machine. +The second command would start IcmpPing test from the LNST test library on the test machine with id=1. -You can also access the configuration of machines and their interfaces from -the command sequence through a special alias {$recipe}. In the -previous example, addr option of IcmpPing test will be set to first -assigned address from netconfig of first device on second -machine. +You can also access the configuration of machines and their interfaces from the command sequence through a special alias {$recipe}. In the previous example, addr option of IcmpPing test will be set to first assigned address from netconfig of first device on second machine. +<h4>Running commands in background</h4> + +Every command can be run in background. To put a command in background add the bg_id attribute to the command tag and set it's value to unique identifier, e.g. a number or a string like "iperf_server_in_bg". This identifier is later used to interrupt (intr or kill) the command or wait for it's completion(wait). +Look at following example: + +<pre><command_sequence> + <command type="test" machine_id="server" value="Iperf" bg_id="iperf_server_in_bg"> + <options> + <option name="bind" value="{ip(server,testifc1)}" /> + <option name="role" value="server"/> + </options> + </command> + <command type="exec" value="sleep 3"/> + <command type="test" machine_id="client" value="Iperf"> + <options> + <option name="iperf_server" value="{ip(server,testifc1)}" /> + <option name="role" value="client"/> + <option name="duration" value="10"/> + </options> + </command> + <command type="intr" machine_id="server" value="iperf_server_in_bg"/> +</command_sequence></pre> + + + <h3>System Configuration</h3> -LNST provides a native way of changing system configuration of the slave machines from within the recipe. -This can be achieved by system_config command. There are two versions -of system_config command: +LNST provides a native way of changing system configuration of the slave machines from within the recipe. This can be achieved by system_config command. There are two versions of system_config command: <h4>Inline version</h4> <pre> @@ -401,9 +363,8 @@ of system_config command: In the multiline version you can set a several options at once. - Unless persistent flag is set to true, all modified - options are restored to their previous values at the end of the command sequence. - The following examlpe illustrates how this works: + Unless persistent flag is set to true, all modified options are restored to their previous values at the end of the command sequence. + The following example illustrates how this works: <pre> <command_sequence> <command type="system_config" machine_id="1" persistent="true"> @@ -428,31 +389,24 @@ of system_config command: </command_sequence> </pre> - The first command sequence serves as a global system setup phase, persistent flag is set to true, - so the options will not be restored when the command sequence finishes. + The first command sequence serves as a global system setup phase, persistent flag is set to true, so the options will not be restored when the command sequence finishes. - In the second command sequence, one option is modified for purposes of the next test, but it's - not marked persistent, so the change will be automatically reverted when the command sequence - comes to end. + In the second command sequence, one option is modified for purposes of the next test, but it's not marked persistent, so the change will be automatically reverted when the command sequence comes to end. - And the final command sequences issues a persistent command again, to make sure that system is left - in a consistent state when recipe execution is over. + And the final command sequences issues a persistent command again, to make sure that system is left in a consistent state when recipe execution is over. <hr /> -<h2>Writing a test</h2> +<h2>Advanced recipe techniques</h2> This section introduces several features you can use when you decide to create your own recipe. <h3>Defining aliases</h3> -LNST allows you to define arbitrary aliases and use -them to access certain values from the whole recipe file while the value -itself is included in the file only once. Definition of an alias occurs -in the <code><define></code> tag anywhere in the document: +LNST allows you to define arbitrary aliases and use them to access certain values from the whole recipe file while the value itself is included in the file only once. Definition of an alias occurs in the <code><define></code> tag anywhere in the document: <pre> <define> <alias name="ip_addr" value="192.168.0.1" /> @@ -472,9 +426,7 @@ For instance: <h3>Template functions</h3> - Template functions are conceptually quite similar to aliases, but instead of a assigned value, they - represent an action that will be executed when the recipe is parsed. They can be used the same way - as aliases - inside of curly braces. Currently, there are three template functions available in LNST: + Template functions are conceptually quite similar to aliases, but instead of a assigned value, they represent an action that will be executed when the recipe is parsed. They can be used the same way as aliases - inside of curly braces. Currently, there are three template functions available in LNST: <ul> <li>ip(machine_id, interface_id[, address_id]) @@ -496,9 +448,7 @@ For instance: </li> </ul> - All three above mentioned functions can be used for retrieving information from machine - configs, therefore calling them is only valid within a command sequence. See the following - example on how this templates can be used: + All three above mentioned functions can be used for retrieving information from machine configs, therefore calling them is only valid within a command sequence. See the following example on how this templates can be used: <pre> <command type="system_config" option="/proc/sys/net/ipv4/conf/{devname(1,1)}/forwarding" value="1" machine_id="1" /> @@ -511,18 +461,12 @@ For instance: </command> </pre> - Aliases can be passed to functions as parameters, but the preprocessor -does not support nesting (e.g. function cannot have another function -passed as an argument). + Aliases can be passed to functions as parameters, but the preprocessor does not support nesting (e.g. function cannot have another function passed as an argument). <h3>Splitting recipes into multiple files</h3> -LNST also offers a possibility of splitting the recipe into several -files. This can be achieved by supplying source argument -to an arbitrary tag. The contents of that tag then will be loaded from the -file specified in the attribute's value. For instance, the following -machine configuration will be loaded from file peanut.xml: +LNST also offers a possibility of splitting the recipe into several files. It's very helpful if you want to re-use the code in different recipes. This can be achieved by supplying source argument to an arbitrary tag. The contents of that tag then will be loaded from the file specified in the attribute's value. For instance, the following machine configuration will be loaded from file peanut.xml: <pre> <machine source="machine_configs/peanut.xml" /> @@ -530,7 +474,7 @@ machine configuration will be loaded from file peanut.xml: Example (peanut.xml): <pre> <machine id="1"> - <netmachineconfig source="example_recipes/machine_configs/config-f14peanut.xml" /> + <machineconfig source="example_recipes/machine_configs/config-f14peanut.xml" /> <netconfig source="example_recipes/net_configs/netconfig1.xml" /> </machine> </pre> @@ -539,6 +483,10 @@ Example (peanut.xml): <hr /> +<h2>Writing a test</h2> + +<hr /> + <h2>Running in virtual environment</h2> @@ -548,12 +496,7 @@ Example (peanut.xml): start <domain></li> </ul> -Following is an example of libvirt xmls (reduced to network snippets only). -MAC addresses marked with green color should be specified in the relevant -machine configs. Don't forget to add dedicated control network interface that -has to stay up during the whole testing. The configuration below expects that -virt guests are accessible via host's network interface therefore they're set -up as type='bridge'. +Following is an example of libvirt xmls (reduced to network snippets only). MAC addresses marked with green color should be specified in the relevant machine configs. Don't forget to add dedicated control network interface that has to stay up during the whole testing. The configuration below expects that virt guests are accessible via host's network interface therefore they're set up as type='bridge'. <pre><domain type='kvm'> <name>rhel5.6-snap1</name> ... @@ -610,30 +553,18 @@ up as type='bridge'. <h3>Running LNST using remote execution</h3> On the controller machine run following command: -<pre>> ./nettestctl.py -e -c -r my_recipe.xml run</pre> +<pre>> ./nettestctl.py -e -c my_recipe.xml run</pre> -The -e option of the nettestctl.py command tells the -controller to make SSH connections to all machines specified in the xml file -my_recipe.xml and start nettestslave.py processes on these machines. The -nettestslave.py processes will start listening for XMLRPC connections through -which the network interfaces will get configured. The -c -option tells the controller to cleanup the test machines before any network -configuration, that means removal of relevant kernel module (bonding, bridge, -8021q, etc.). +The -e option of the nettestctl.py command tells the controller to make SSH connections to all machines specified in the xml file my_recipe.xml copy the LNST code to the machines and start nettestslave.py processes on these machines. The nettestslave.py processes will start listening for XMLRPC connections through which the network interfaces will get configured. The -c option tells the controller to cleanup the test machines before any network configuration, that means removal of relevant kernel module (bonding, bridge, 8021q, etc.). <h3>Running LNST without remote execution</h3> -In this case you have to start nettestslave.py processes first on all -machines that are defined in recipe by yourself. Let's assume there are -2 machines participating in the test. +In this case you have to start nettestslave.py processes first on all machines that are defined in recipe by yourself. Let's assume there are 2 machines participating in the test. On both of these machines you have to run following command: <pre>$ ./nettestslave.py [-d]</pre> -If anything goes wrong it is a good practice to pass the debug option --d because you will get information about established xmlrpc -connection from the controller and also information about getting the network -test interfaces ready and possible problems during the setup. +If anything goes wrong it is a good practice to pass the debug option -d because you will get information about established xmlrpc connection from the controller and also information about getting the network test interfaces ready and possible problems during the setup. After a successful startup you should get following line on the output: <pre>$ ./nettestslave.py @@ -641,16 +572,14 @@ test interfaces ready and possible problems during the setup. After that you need to start nettestctl.py on the controller to run the test in a recipe: -<pre>$ ./nettestctl.py -c -r my_recipe.xml run</pre> +<pre>$ ./nettestctl.py -c my_recipe.xml run</pre> <h3>Using LNST to configure interfaces only</h3> -You can also use LNST to do just the network configuration of the test -machines. None of the tests inside your recipe file will get executed. +You can also use LNST to do just the network configuration of the test machines. None of the tests inside your recipe file will get executed. -To do this pass config_only instead of 'run' argument to -nettestctl.py script. -<pre>$ ./nettestctl.py -r my_recipe.xml config_only</pre> +To do this pass config_only instead of 'run' argument to nettestctl.py script. +<pre>$ ./nettestctl.py my_recipe.xml config_only</pre> </body>

11 years, 5 months

1
0
0 / 0

[PATCH] Update the documentation

by Jan Tluka

This is an update of the project documentation to reflect the many changes in the last few months. Signed-off-by: Jan Tluka <jtluka(a)redhat.com> --- Documentation/LNSTIntro.html | 317 ++++++++++++++++-------------------------- 1 files changed, 123 insertions(+), 194 deletions(-) diff --git a/Documentation/LNSTIntro.html b/Documentation/LNSTIntro.html index baea586..8df17b1 100644 --- a/Documentation/LNSTIntro.html +++ b/Documentation/LNSTIntro.html @@ -13,14 +13,13 @@ </head> <body> -<h1>LNST Project</h1> +<h1>Linux Network Stack Test - LNST Project</h1> <h2>About</h2> -LNST is an automated testing framework focused on the Linux network stack -testing. It supports bonding, vlan, bridging and macvlan. +LNST is an automated testing framework focused on the Linux network stack testing. It supports bonding, vlan, bridging and macvlan. <h3>People</h3> <ul> @@ -29,12 +28,14 @@ testing. It supports bonding, vlan, bridging and macvlan. quality engineer</li> <li>Jan Tluka (jtluka) – contributor, test development, Beaker integration, quality engineer</li> - <li>Radek Pazdera - contributor, framework infrastructure implementation, test development, quality engineer + <li>Radek Pazdera (rpazdera) - contributor, framework infrastructure implementation, test development, quality engineer + <li>Ondrej Lichtner (olichtne) - contributor, framework infrastructure implementation, quality engineer </ul> <h3>Communication channels</h3> <ul> + <li>Project web page on <a>https://fedorahosted.org/lnst/</a> <li>We are on irc: #lnst @ freenode (irc://irc.freenode.net#lnst)</li> <li>The development mailing list: <a href="https://fedorahosted.org/mailman/listinfo/lnst-developers">https://fedorahosted.org/mailman/listinfo/lnst-developers</a></li> </ul> @@ -43,8 +44,7 @@ testing. It supports bonding, vlan, bridging and macvlan. <h3>Goals</h3> <ul> <li>QE: extend our current network code coverage in Tier tests</li> - <li>Devel: create a tool/test environment to easily catch regressions in - network stack during development</li> + <li>Devel: create a tool/test environment to easily catch regressions in network stack during development</li> </ul> <h3>Target audience</h3> @@ -55,8 +55,7 @@ testing. It supports bonding, vlan, bridging and macvlan. <h3>Topology</h3> -In the following picture you can see an example of the network topology -along with the roles and communication paths. There are 3 basic entities, +In the following picture you can see an example of the network topology along with the roles and communication paths. There are 3 basic entities, <ul> <li>controller </li> <li>test machines</li> @@ -72,17 +71,11 @@ width="712" height="279" /> -In the picture you can see two network connections drawn in different -colors. +In the picture you can see two network connections drawn in different colors. -The green one is the controller path and is used to setup -network interfaces on machine1 and machine2 through the controller -interfaces (eth3 on both test machines). The controller -path is also used to do setup of the test switch and live changes on -it such as vlan and bonding configuration, port disconnection, etc. +The green one is the controller path and is used to setup network interfaces on machine1 and machine2 through the controller interfaces (eth3 on both test machines). The controller path is also used to do setup of the test switch and live changes on it such as vlan and bonding configuration, port disconnection, etc. -The red one is the test path and is used for network -traffic generated in tests executed on test machines. +The red one is the test path and is used for network traffic generated in tests executed on test machines. <hr /> @@ -103,63 +96,27 @@ traffic generated in tests executed on test machines. <h2>Source code structure</h2> +Please note, that not every file is listed. + <pre>[./] - netconfig.py (tool to configure network interfaces based on xml description) nettestctl.py (tool to control remote machines/execute tests) nettestslave.py (app that runs on remote machine and accepts commands from controller (nettestctl.py)) - switchconfig.py - swswitch.py [./Common] (common code for the framework) - Daemon.py - ExecCmd.py - LoggingServer.py - Logs.py - ProcessManager.py - ShellProcess.py - SlaveUtils.py - SshUtils.py - TestsCommon.py - Utils.py - XmlPreprocessor.py - XmlRpc.py - -[./example_recipes] (inspiration for test setups – netconfigs, machineconfigs, recipes) + +[./recipes] (inspiration for test setups – netconfigs, machineconfigs, recipes) [./NetConfig] (network configuration class implementation) - NetConfigCommon.py - NetConfigDevice.py - NetConfigDevNames.py - NetConfigParse.py (netconfig xml parser) - NetConfig.py [./NetTest] (test execution class implementation) - NetTestCommand.py - NetTestController.py - NetTestParse.py - NetTestParse.pyc - NetTestResultSerializer.py - NetTestSlave.py - -[./Switch] (network switch configuration) - SwitchConfigParse.py - SwitchCtl.py - SwitchDriversCommon.py + +[./Switch] (network switch configuration implementation) [./Tests] (implementation of network tests) - TestDummyFailing.py - TestIcmp6Ping.py - TestIcmpPing.py - TestIperf.py - TestMulticast.py - TestNetCat.py - TestPktCounter.py - TestPktgenTx.py - -[./test_tools] (non-python testing tools and scripts) - multicast/ + +[./test_tools] (place to keep non-python testing tools and scripts) </pre> @@ -167,22 +124,16 @@ traffic generated in tests executed on test machines. <h2>Setting up the test environmnent</h2> -<h3>Remote connection setup</h3> +<h3>Controller-Slave connection setup</h3> -Every test machine has to be configured to allow remote SSH connection. This -can be achieved either using keys or specifying root password in XML files -(described below). It's mandatory to have a dedicated control network interface -for the SSH connection that is used to setup network on additional network -interfaces and execute tests. It is also important to separate "controller -path" and "test path" infrastructure, e.g. using two switches. + +It's mandatory to have a dedicated controller network interface on all of the test machines for both the XML-RPC connection that is used to setup network interfaces for testing and for the test execution itself. By default the xml-rpc client listens on port 9999 so if you use firewall of any sort this port needs to be open. If you want to run the tests using the "remote execution" (see chapter The Workflow - running LNST at the end of this document) you also need to have SSH daemon running on all of the test machines. It is also important to separate "controller path" and "test path" infrastructure, e.g. using two switches. <h3>Required packages</h3> -Basically you need to have python installed. If you use RHEL5 on a machine -you need to install additional package python-ctypes from EPEL -repository on it. +Basically you need to have python installed. If you use RHEL5 on a machine you need to install additional package python-ctypes from EPEL repository on it. <ul> <li><a href="http://fedoraproject.org/wiki/EPEL">http://fedoraproject.org/wiki/EPEL</a></li> @@ -193,30 +144,40 @@ repository on it. install python-ctypes</li> </ul> +<h3>Optional packages</h3> + +It is recommended to install following packages. Either optional framework features rely on them or the LNST tests require them to do their work. +<ul> + <li>tcpdump</li> + <li>nc (netcat)</li> + <li>iperf</li> + <li>iptables</li> +</ul> + <hr /> <h2>LNST Recipes</h2> -The LNST recipes contains all information to do a test run. +The LNST recipe contains all information to do a test run. It consists of: <ul> - <li>machineconfigs</li> - <li>netconfigs</li> - <li>command sequences</li> + <li>machineconfigs - to define the set of machines under testing</li> + <li>netconfigs - to define how the network interfaces should be configured</li> + <li>command sequences - to define all test sub-tasks</li> </ul> The following XML code is an example of the LNST recipe: <pre><nettestrecipe> <machines> <machine id="1"> - <netmachineconfig source="example_recipes/machine_configs/config-f14peanut.xml"/> - <netconfig source="example_recipes/net_configs/netconfig1.xml"/> + <machineconfig source="recipes/team/machineconfig-test1.xml"/> + <netconfig source="recipes/team/netconfig-simple.xml"/> </machine> <machine id="2"> - <netmachineconfig source="my_recipes/config-f15.xml"/> - <netconfig source="my_recipes/netconfig2.xml"/> + <machineconfig source="recipes/team/machineconfig-test2.xml"/> + <netconfig source="recipes/team/netconfig-team_ab_lw_001.xml"/> </machine> </machines> @@ -224,7 +185,7 @@ repository on it. <command type="exec" value="sleep 4"/> <command type="test" machine_id="1" value="IcmpPing" timeout="30"> <options> - <option type="recipe_eval" name="addr" value="['machines'][2]['netconfig'][1]['addresses'][0]"/> + <option name="addr" value="{ip(2,testip)}"/> <option name="count" value="40"/> <option name="interval" value="0.2"/> <option name="limit_rate" value="95"/> @@ -235,48 +196,40 @@ repository on it. -Every test machine's network setup is defined by two configuration XML -snippets – MachineConfig describing the machine's real hardware (available -NICs) and NetConfig describing configuration of these devices (IP addresses, -bonding setup, bridging, vlans, etc.) +Every test machine's network setup is defined by two configuration XML snippets – MachineConfig describing the machine's physical hardware (available NICs) and NetConfig describing configuration of these devices (IP addresses, bonding setup, bridging, vlans, etc.) <h3>MachineConfig</h3> The MachineConfig <ul> - <li>describes test machine's control interface and login information (for - root access) - info tag</li> - <li>describes available network interfaces of a test machine – - netdevice tags</li> + <li>describes test machine's control interface and root login information (for remote execution) - info tag</li> + <li>describes available network interfaces of a test machine – netdevice tags</li> </ul> -Example (example_recipes/machine_configs/config-f14peanut.xml): +Example: -<pre><netmachineconfig> +<pre><machineconfig> <info hostname="10.34.37.141" rootpass="aaa"/> - <netdevice type="eth" phys_id="1" hwaddr="00:E0:4C:14:2E:5D"/> - <netdevice type="eth" phys_id="2" hwaddr="00:30:4F:7F:FD:30"/> -</netmachineconfig></pre> + <netdevices> + <netdevice type="eth" network="testnet" phys_id="1" hwaddr="00:E0:4C:14:2E:5D"/> + <netdevice type="eth" network="testnet" phys_id="2" hwaddr="00:30:4F:7F:FD:30"/> + </netdevices> +</machineconfig></pre> -Test machine with this configuration will be accessible via IP address -10.34.37.141 using root password 'aaa' (rootpass). Two -interfaces are made available for testing - one with MAC address -00:E0:4C:14:2E:5D (hwaddr) exported as physical device '1' -(phys_id) and second with MAC address 00:30:4F:7F:FD:30 -exported as physical device '2' in LNST framework. +Test machine with this configuration will be accessible via IP address 10.34.37.141 using root password 'aaa' (rootpass). Two interfaces are made available for testing - one with MAC address 00:E0:4C:14:2E:5D (hwaddr) exported as physical device '1' (phys_id) and second with MAC address 00:30:4F:7F:FD:30 exported as physical device '2' in LNST framework. <h3>NetConfig</h3> -Example (example_recipes/net_configs/netconfig1.xml): +Example: <pre><netconfig> - <netdevice id="1" type="eth" phys_id="1"/> - <netdevice id="2" type="eth" phys_id="2"/> - <netdevice id="3" type="bond"> + <interface id="1" type="eth" phys_id="1"/> + <interface id="2" type="eth" phys_id="2"/> + <interface id="testifc1" type="bond"> <options> <option name="mode" value="1"/> <option name="miimon" value="100"/> @@ -289,19 +242,15 @@ exported as physical device '2' in LNST framework. <addresses> <address value="192.168.101.1/24"/> </addresses> - </netdevice> + </interface> </netconfig></pre> This configuration snippet uses two physical devices -(phys_id="1" and phys_id="2") defined in the -previous MachineConfig. It also defines third network device (netdevice -id="3") as bond device and adds the two physical -device as its slaves. Further options are defined in -options element and IP address of the bond interface is -defined in addresses element. +(phys_id="1" and phys_id="2") defined in the previous MachineConfig. It also defines third network device (netdevice id="3") as bond device and adds the two physical device as its slaves. Further options are defined in options element and IP address of the bond interface is defined in addresses element. +Please note that you can use strings instead of just numbers for interface identification. This is very helpful when you're referring these interfaces in your command sequences. More on this in following chapter. <h3>Mapping of physical interfaces inside LNST recipes</h3> @@ -316,13 +265,17 @@ src="machineconfig-netconfig-mapping.png" width="793" height="318" /> <h3>Command sequences</h3> -Command sequence in a LNST recipe is a list of commands that is executed -on test machines or controller. +Command sequence in a LNST recipe is a list of commands that is executed on test machines or controller. -Tasks can be of type: +<h4>Commands</h4> + +Commands can be of type: <ul> - <li>exec or</li> - <li>test (can be run on test machines only)</li> + <li>type="exec" or</li> + <li>type="test"(can be run on test machines only)</li> + <li>type="intr" to interrupt (SIG_INT) commands running in background</li> + <li>type="kill" to kill (SIG_KILL) commands running in background</li> + <li>type="wait" to wait for completion of a command running in background</li> </ul> The exec command is anything that you can enter on a @@ -334,12 +287,7 @@ command line. E.g. -The test command is an implemented test. The code of the -test is present in Tests/TestIcmpPing.py in the example below. -You can pass variables to a test using option tag. The options -value can be obtained using get_opt() method. For further -details see section Writing tests or look at code examples -under Tests directory. +The test command is an implemented test. The code of the test in the example below is present in Tests/TestIcmpPing.py. You can pass variables to a test using the option tag. The option value can be obtained using get_opt(),get_mopt() methods. For further details see section Writing tests or look at code examples under Tests directory. @@ -360,27 +308,41 @@ under Tests directory. There are two commands in this example. -First one would execute command sleep on the controller machine because -attribute machine_id is not supplied (default behavior). The -machine_id attributes defines on which of the test machines -command is run. It's value matches one of the machine ids defined in -<machine> tag in LNST recipe. +First one would execute command sleep on the controller machine because attribute machine_id is not supplied (default behavior). The machine_id attribute defines on which of the test machines command should run. It's value matches one of the machine ids defined in <machine> tag in LNST recipe. -The second command would start IcmpPing test from the -LNST library on the first (id=1) test machine. +The second command would start IcmpPing test from the LNST test library on the test machine with id=1. -You can also access the configuration of machines and their interfaces from -the command sequence through a special alias {$recipe}. In the -previous example, addr option of IcmpPing test will be set to first -assigned address from netconfig of first device on second -machine. +You can also access the configuration of machines and their interfaces from the command sequence through a special alias {$recipe}. In the previous example, addr option of IcmpPing test will be set to first assigned address from netconfig of first device on second machine. +<h4>Running commands in background</h4> + +Every command can be run in background. To put a command in background add the bg_id attribute to the command tag and set it's value to unique identifier, e.g. a number or a string like "iperf_server_in_bg". This identifier is later used to interrupt (intr or kill) the command or wait for it's completion(wait). +Look at following example: + +<pre><command_sequence> + <command type="test" machine_id="server" value="Iperf" bg_id="iperf_server_in_bg"> + <options> + <option name="bind" value="{ip(server,testifc1)}" /> + <option name="role" value="server"/> + </options> + </command> + <command type="exec" value="sleep 3"/> + <command type="test" machine_id="client" value="Iperf"> + <options> + <option name="iperf_server" value="{ip(server,testifc1)}" /> + <option name="role" value="client"/> + <option name="duration" value="10"/> + </options> + </command> + <command type="intr" machine_id="server" value="iperf_server_in_bg"/> +</command_sequence></pre> + + + <h3>System Configuration</h3> -LNST provides a native way of changing system configuration of the slave machines from within the recipe. -This can be achieved by system_config command. There are two versions -of system_config command: +LNST provides a native way of changing system configuration of the slave machines from within the recipe. This can be achieved by system_config command. There are two versions of system_config command: <h4>Inline version</h4> <pre> @@ -401,9 +363,8 @@ of system_config command: In the multiline version you can set a several options at once. - Unless persistent flag is set to true, all modified - options are restored to their previous values at the end of the command sequence. - The following examlpe illustrates how this works: + Unless persistent flag is set to true, all modified options are restored to their previous values at the end of the command sequence. + The following example illustrates how this works: <pre> <command_sequence> <command type="system_config" machine_id="1" persistent="true"> @@ -428,31 +389,24 @@ of system_config command: </command_sequence> </pre> - The first command sequence serves as a global system setup phase, persistent flag is set to true, - so the options will not be restored when the command sequence finishes. + The first command sequence serves as a global system setup phase, persistent flag is set to true, so the options will not be restored when the command sequence finishes. - In the second command sequence, one option is modified for purposes of the next test, but it's - not marked persistent, so the change will be automatically reverted when the command sequence - comes to end. + In the second command sequence, one option is modified for purposes of the next test, but it's not marked persistent, so the change will be automatically reverted when the command sequence comes to end. - And the final command sequences issues a persistent command again, to make sure that system is left - in a consistent state when recipe execution is over. + And the final command sequences issues a persistent command again, to make sure that system is left in a consistent state when recipe execution is over. <hr /> -<h2>Writing a test</h2> +<h2>Advanced recipe techniques</h2> This section introduces several features you can use when you decide to create your own recipe. <h3>Defining aliases</h3> -LNST allows you to define arbitrary aliases and use -them to access certain values from the whole recipe file while the value -itself is included in the file only once. Definition of an alias occurs -in the <code><define></code> tag anywhere in the document: +LNST allows you to define arbitrary aliases and use them to access certain values from the whole recipe file while the value itself is included in the file only once. Definition of an alias occurs in the <code><define></code> tag anywhere in the document: <pre> <define> <alias name="ip_addr" value="192.168.0.1" /> @@ -472,9 +426,7 @@ For instance: <h3>Template functions</h3> - Template functions are conceptually quite similar to aliases, but instead of a assigned value, they - represent an action that will be executed when the recipe is parsed. They can be used the same way - as aliases - inside of curly braces. Currently, there are three template functions available in LNST: + Template functions are conceptually quite similar to aliases, but instead of a assigned value, they represent an action that will be executed when the recipe is parsed. They can be used the same way as aliases - inside of curly braces. Currently, there are three template functions available in LNST: <ul> <li>ip(machine_id, interface_id[, address_id]) @@ -496,9 +448,7 @@ For instance: </li> </ul> - All three above mentioned functions can be used for retrieving information from machine - configs, therefore calling them is only valid within a command sequence. See the following - example on how this templates can be used: + All three above mentioned functions can be used for retrieving information from machine configs, therefore calling them is only valid within a command sequence. See the following example on how this templates can be used: <pre> <command type="system_config" option="/proc/sys/net/ipv4/conf/{devname(1,1)}/forwarding" value="1" machine_id="1" /> @@ -511,18 +461,12 @@ For instance: </command> </pre> - Aliases can be passed to functions as parameters, but the preprocessor -does not support nesting (e.g. function cannot have another function -passed as an argument). + Aliases can be passed to functions as parameters, but the preprocessor does not support nesting (e.g. function cannot have another function passed as an argument). <h3>Splitting recipes into multiple files</h3> -LNST also offers a possibility of splitting the recipe into several -files. This can be achieved by supplying source argument -to an arbitrary tag. The contents of that tag then will be loaded from the -file specified in the attribute's value. For instance, the following -machine configuration will be loaded from file peanut.xml: +LNST also offers a possibility of splitting the recipe into several files. It's very helpful if you want to re-use the code in different recipes. This can be achieved by supplying source argument to an arbitrary tag. The contents of that tag then will be loaded from the file specified in the attribute's value. For instance, the following machine configuration will be loaded from file peanut.xml: <pre> <machine source="machine_configs/peanut.xml" /> @@ -530,7 +474,7 @@ machine configuration will be loaded from file peanut.xml: Example (peanut.xml): <pre> <machine id="1"> - <netmachineconfig source="example_recipes/machine_configs/config-f14peanut.xml" /> + <machineconfig source="example_recipes/machine_configs/config-f14peanut.xml" /> <netconfig source="example_recipes/net_configs/netconfig1.xml" /> </machine> </pre> @@ -539,6 +483,10 @@ Example (peanut.xml): <hr /> +<h2>Writing a test</h2> + +<hr /> + <h2>Running in virtual environment</h2> @@ -548,12 +496,7 @@ Example (peanut.xml): start <domain></li> </ul> -Following is an example of libvirt xmls (reduced to network snippets only). -MAC addresses marked with green color should be specified in the relevant -machine configs. Don't forget to add dedicated control network interface that -has to stay up during the whole testing. The configuration below expects that -virt guests are accessible via host's network interface therefore they're set -up as type='bridge'. +Following is an example of libvirt xmls (reduced to network snippets only). MAC addresses marked with green color should be specified in the relevant machine configs. Don't forget to add dedicated control network interface that has to stay up during the whole testing. The configuration below expects that virt guests are accessible via host's network interface therefore they're set up as type='bridge'. <pre><domain type='kvm'> <name>rhel5.6-snap1</name> ... @@ -610,30 +553,18 @@ up as type='bridge'. <h3>Running LNST using remote execution</h3> On the controller machine run following command: -<pre>> ./nettestctl.py -e -c -r my_recipe.xml run</pre> +<pre>> ./nettestctl.py -e -c my_recipe.xml run</pre> -The -e option of the nettestctl.py command tells the -controller to make SSH connections to all machines specified in the xml file -my_recipe.xml and start nettestslave.py processes on these machines. The -nettestslave.py processes will start listening for XMLRPC connections through -which the network interfaces will get configured. The -c -option tells the controller to cleanup the test machines before any network -configuration, that means removal of relevant kernel module (bonding, bridge, -8021q, etc.). +The -e option of the nettestctl.py command tells the controller to make SSH connections to all machines specified in the xml file my_recipe.xml copy the LNST code to the machines and start nettestslave.py processes on these machines. The nettestslave.py processes will start listening for XMLRPC connections through which the network interfaces will get configured. The -c option tells the controller to cleanup the test machines before any network configuration, that means removal of relevant kernel module (bonding, bridge, 8021q, etc.). <h3>Running LNST without remote execution</h3> -In this case you have to start nettestslave.py processes first on all -machines that are defined in recipe by yourself. Let's assume there are -2 machines participating in the test. +In this case you have to start nettestslave.py processes first on all machines that are defined in recipe by yourself. Let's assume there are 2 machines participating in the test. On both of these machines you have to run following command: <pre>$ ./nettestslave.py [-d]</pre> -If anything goes wrong it is a good practice to pass the debug option --d because you will get information about established xmlrpc -connection from the controller and also information about getting the network -test interfaces ready and possible problems during the setup. +If anything goes wrong it is a good practice to pass the debug option -d because you will get information about established xmlrpc connection from the controller and also information about getting the network test interfaces ready and possible problems during the setup. After a successful startup you should get following line on the output: <pre>$ ./nettestslave.py @@ -641,16 +572,14 @@ test interfaces ready and possible problems during the setup. After that you need to start nettestctl.py on the controller to run the test in a recipe: -<pre>$ ./nettestctl.py -c -r my_recipe.xml run</pre> +<pre>$ ./nettestctl.py -c my_recipe.xml run</pre> <h3>Using LNST to configure interfaces only</h3> -You can also use LNST to do just the network configuration of the test -machines. None of the tests inside your recipe file will get executed. +You can also use LNST to do just the network configuration of the test machines. None of the tests inside your recipe file will get executed. -To do this pass config_only instead of 'run' argument to -nettestctl.py script. -<pre>$ ./nettestctl.py -r my_recipe.xml config_only</pre> +To do this pass config_only instead of 'run' argument to nettestctl.py script. +<pre>$ ./nettestctl.py my_recipe.xml config_only</pre> </body> -- 1.7.7.6

11 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

LNST-developers November 2012