[lnst trac] #50: Wiki article: How to Structure LNST Recipes
by fedora-badges
#50: Wiki article: How to Structure LNST Recipes
----------------------+------------------------------------------
Reporter: rpazdera | Owner:
Type: task | Status: new
Priority: major | Milestone: Complete Wiki Documentation
Component: wiki | Version:
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------------------------
This article should cover everything about lnst recipe creation from a
point of view of an inexperienced LNST user.
It should be easy to understand and not too technical. It doesn't have to
cover the topic completely, but it should give enough information for a
newcomer.
This article should incorporate the topic in the 4th section of the LNST
Intro document.
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/50>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
10 years, 7 months
[lnst trac] #52: Wiki article: Machine Config XML Reference
by fedora-badges
#52: Wiki article: Machine Config XML Reference
----------------------+------------------------------------------
Reporter: rpazdera | Owner:
Type: task | Status: new
Priority: major | Milestone: Complete Wiki Documentation
Component: wiki | Version:
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------------------------
There should be a separate reference for the XML format of machine configs
that belong to a pool directory. It should be a brief enumeration of
values for advanced users (the guide for beginners will be placed
separately).
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/52>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
10 years, 7 months
[lnst trac] #73: Coloured output to terminal
by fedora-badges
#73: Coloured output to terminal
-------------------------+-----------------------------
Reporter: rpazdera | Owner: rpazdera
Type: enhancement | Status: new
Priority: minor | Milestone: Stable Release
Component: lnst-ctl | Version: git
Keywords: | Blocked By:
Blocking: |
-------------------------+-----------------------------
It would be nice, if the terminal output of LNST was coloured. LNST prints
out lots of messages and colouring would make them much easier to read.
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/73>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
10 years, 8 months
[lnst trac] #59: TestPacketAssert: pipe buffering bug
by fedora-badges
#59: TestPacketAssert: pipe buffering bug
----------------------+------------------
Reporter: olichtne | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: lnst-ctl | Version: git
Keywords: | Blocked By:
Blocking: |
----------------------+------------------
There seems to be a bug caused by using pipes for reading output of the
tcpdump command. Parts of the output are not read often resulting in fail
state of the command.
I think it is connected to buffering of these pipes as sometimes it does
appear and other times it works correctly. The problem could also be
connected to the fact that the program is being run in the background and
is therefore interrupted by a signal, the handler of the signal doesn't
read the rest of the output which it probably should.
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/59>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
10 years, 10 months
[lnst trac] #71: "Unknown RPC method" not handled
by fedora-badges
#71: "Unknown RPC method" not handled
----------------------+-----------------------------
Reporter: rpazdera | Owner: olichtne
Type: defect | Status: new
Priority: minor | Milestone: Stable Release
Component: lnst-ctl | Version: git
Keywords: | Blocked By:
Blocking: |
----------------------+-----------------------------
There is a minor issue in the controller; it seems to crash when it
receives an "unknown RPC method" error as an answer to a RPC call. This
doesn't happen very often, but it should be supported.
Reproducer:
Change the 'hello' rpc call in the code to "wtfomg" and it should produce
this error.
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/71>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
10 years, 10 months
[PATCH] NetTestController: handling of error messages
by Ondrej Lichtner
From: Ondrej Lichtner <olichtne(a)redhat.com>
The communication protocol that was implemented can also send error
messages, however the Controller wasn't handling them and instead raised
an Unknown message exception. This patch fixes that by raising an
exception with the correct message.
I also modified the message that Slave sends when an unsupported method
call is recieved.
Signed-off-by: Ondrej Lichtner <olichtne(a)redhat.com>
---
lnst/Controller/NetTestController.py | 4 ++++
lnst/Slave/NetTestSlave.py | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/lnst/Controller/NetTestController.py b/lnst/Controller/NetTestController.py
index 62600ca..169f0af 100644
--- a/lnst/Controller/NetTestController.py
+++ b/lnst/Controller/NetTestController.py
@@ -394,6 +394,10 @@ class MessageDispatcher(ConnectionHandler):
elif message[1]["type"] == "exception":
msg = "Recieved an exception from slave: %s" % message[0]
raise CommandException(msg)
+ elif message[1]["type"] == "error":
+ msg = "Recieved an error message from slave %s: %s" %\
+ (message[0], message[1]["err"])
+ raise CommandException(msg)
else:
msg = "Unknown message type: %s" % message[1]["type"]
raise NetTestError(msg)
diff --git a/lnst/Slave/NetTestSlave.py b/lnst/Slave/NetTestSlave.py
index 2b0def5..9b39c0a 100644
--- a/lnst/Slave/NetTestSlave.py
+++ b/lnst/Slave/NetTestSlave.py
@@ -437,7 +437,7 @@ class NetTestSlave:
self._cmd_context.cleanup()
self._log_ctl.cancel_connection()
else:
- err = "Method not found: %s" % msg["method_name"]
+ err = "Method '%s' not supported." % msg["method_name"]
response = {"type": "error", "err": err}
if not self._server_handler.send_data_to_ctl(response):
self._cmd_context.cleanup()
--
1.7.11.7
10 years, 10 months
[PATCH 0/7] Virt support for the matching algorithm
by Radek Pazdera
This series finishes what have been started during the refactoring of
the NetTestController in the previous one. LNST now supports automatic
configuration of virtual machines based on the description of the in
the recipe file.
It is done during the macthing phase. LNST first tries to match the
network against the pool normaly and in case it fails, it will try
to find a set of suitable virtual machines (those with libvirt_domain
specified) to configure.
Then the configuration of the network connections between the virtual
guests is done automatically using libvirt. It will add interfaces to
the machines and connect them together through bridges on the controller.
There are a few limitations however. The machines must be virtualized
directly on the controller. And in case you want to use this feature,
you need to run lnst-ctl with root priviledges, so it can use brctl and
virsh.
Radek Pazdera (7):
SlavePool: Support matching virtualized schemes
NetTestSlave: Making the get_iface_info more precise
NetTestController: Fixing a bug in bridges cleanup
Machine: Fixing a number of issues in the virt support
SlavePool: Adding a is_setup_virtual() predicate
VirtUtils: Don't log virsh output
NetTestController: Adding check for root priviledges
lnst/Common/VirtUtils.py | 2 +-
lnst/Controller/Machine.py | 46 +++++++++++++-------
lnst/Controller/NetTestController.py | 9 ++++-
lnst/Controller/SlavePool.py | 77 +++++++++++++++++++++++++++++++--
lnst/Slave/NetTestSlave.py | 23 +++++++++-
5 files changed, 130 insertions(+), 27 deletions(-)
--
1.7.7.6
10 years, 10 months
[PATCH] TestPacketAssert: fix line processing bug
by Ondrej Lichtner
From: Ondrej Lichtner <olichtne(a)redhat.com>
The last two lines from tcpdump were not being processed due to a bug in
the handling loop. This commit fixes that.
Signed-off-by: Ondrej Lichtner <olichtne(a)redhat.com>
---
test_modules/TestPacketAssert.py | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/test_modules/TestPacketAssert.py b/test_modules/TestPacketAssert.py
index 32884a4..0466c20 100644
--- a/test_modules/TestPacketAssert.py
+++ b/test_modules/TestPacketAssert.py
@@ -58,6 +58,8 @@ class TestPacketAssert(TestGeneric):
self.line = next_line
else:
self.line += next_line
+ if self.line != "":
+ self._process_captured_line(self.line)
def _prepare_grep_filters(self):
@@ -152,6 +154,9 @@ class TestPacketAssert(TestGeneric):
else:
self.line += next_line
+ if self.line != "":
+ self._process_captured_line(self.line)
+
logging.info("Capturing finished. Received %d packets", self._num_recv)
res = {"received": self._num_recv,
"min": self._min_cond,
--
1.7.11.7
10 years, 10 months
XML schema and DTD
by Ondrej Lichtner
Hi everyone,
We've wanted to create an XML schema for our recipes for a long time
because it would enable us to validate a recipe before actually passing
it to our parser which also runs external actions while parsing. And
now when we finally have our recipe structure finalized with only small
changes being expected, I decided to create this XML schema.
I have a usable schema ready and I will be attaching it will be attached
to this email. However I first want to note that there are a few
problems with what the schemas can and can not do.
First of all our recipes are designed in a way that some attributes
influence the contents of the associated element, for e.g:
<interface type="eth" network="foo">
<addresses>
<address value="bar"/>
</addresses>
</interface>
vs.
<interface type="bond">
<slaves>
<slave id="1"/>
<slave id="2"/>
</slaves>
</interface>
Not only does the 'type' attribute determine which elements are allowed as
subelements of the 'interface' element, but it also determines if the
attribute 'network' is required or forbidden. This is of course a valid
XML structure, however XML schemas are unable to describe this
situation. According to what I've found this should be done by removing
the element 'interface' and instead use multiple elements
'interface_eth', 'interface_bond', and so on.
The same problem can be also seen in the element 'command' where we have
attributes that are only allowed when 'type' is of a certain value.
And the same can be seen in elements that have either a 'value'
attribute or the value is the contents of the element. This however is
probably just a bad design decision because it introduces
nondeterminism, though I understand why we made it this way.
The next problem I found is that we wanted to define the types of certain
attributes. This could prove to be a little difficult due to our use of
template functions. For example we could have an attribute that expects
an integer and a function that returns that associated integer. However
the schema validation would see the string that calls the function and
not the integer. This could theoretically be solved by extending the
integer type to also accept strings matching a regular expression,
however then we would have different problems and I don't like this
solution in general.
The last problem is a small one- we wanted to make use of the schema to
somehow direct vim to help us with autocompletition when writing
recipes. I've found that this is not possible with XML schemas (unless
we ourselves write the vim script), but it is possible with DTDs, with a
catch. Vim versions 7+ have native ability to autocomplete XMLs by their
DTD, but we have to supply it with a xml-omni-datafile that can be
generated from the DTD. The file then has to be placed in a specific
directory. The full process is described here [1]:
In case anyone wants to try the DTD I have created that as well and will
be attaching it. The DTD has a few more limitations compared to the
schema, mainly some elements have to be in a specific order so watch out
for that.
The problems that I've listed are the reason why I'm not sending the
files as patches. I think that we will have to rethink our usecases for
the XML schema and DTD before I finish them. Our main use case is
definitely recipe validation before it's parsing, which can be done in
two ways:
* rewrite the parser to use a different XML library, from my point
preferably lxml - potentially a lot of work
* do the validation separately and therefore call two different xml
parsers - simple but not as nice looking
If anyone wants to try to validate their recipes the easiest way I found
is to use lxml in python using this tutorial [2]. lxml library is not a
part of python distribution but I have it by default on both my Fedora
machines and my RHEL machines so it shouln't be a problem.
I apologize for the huge email but I wanted to share my thoughts on this
as my exams are coming up so I don't know how if I will be able to
attend meetings.
Any feedback is appreciated.
- Ondrej
[1] http://vimdoc.sourceforge.net/htmldoc/insert.html#ft-xml-omni
[2] http://lxml.de/validation.html
10 years, 10 months
[lnst trac] #58: TestIperf
by fedora-badges
#58: TestIperf
----------------------+------------------
Reporter: olichtne | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: lnst-ctl | Version:
Keywords: | Blocked By:
Blocking: |
----------------------+------------------
Option '''bind''' for this test is mandatory but, if it is not specified
value "None" is used making the corresponding iperf command incorrect and
failing.
Either the default value should be changed or, in my opinion better, this
option should be mandatory seeing as you will probably want to use this on
a testing interface which will most probably not be the default bind
interface.
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/58>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
10 years, 10 months