[lnst trac] #57: TestPacketAssert: Make the 'filter' parameter optional
by fedora-badges
#57: TestPacketAssert: Make the 'filter' parameter optional
----------------------+------------------
Reporter: rpazdera | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: lnst-ctl | Version: git
Keywords: | Blocked By:
Blocking: |
----------------------+------------------
The `filter` option of the test module is mandatory at the moment and an
empty string is allowed to indicate that no filtering should be done.
A better solution would be to make the parameter optional and use the
empty string as default value.
Reported-by: Ondrej Lichtner <olichtne(a)redhat.com>
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/57>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
11 years
[lnst trac] #63: replace xml-rpc with our own protocol
by fedora-badges
#63: replace xml-rpc with our own protocol
-------------------------------------+-----------------------------
Reporter: olichtne | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Stable Release
Component: lnst-ctl and lnst-slave | Version:
Keywords: | Blocked By:
Blocking: |
-------------------------------------+-----------------------------
Today we agreed that our current communication through xml-rpc is not
ideal for our purposes. Instead we want to implement our own communication
protocol that can be used for calling methods on slaves, and transmit data
between the controller and the slaves.
We want to have a separate class that will handle all the connections on
the controller and provide an abstraction over them. The lower level
implementation will probably be based on sending python pickles over
through tcp sockets.
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/63>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
11 years
[lnst trac] #65: Create a class for representing slave machines in LNST
by fedora-badges
#65: Create a class for representing slave machines in LNST
-------------------------+-----------------------------
Reporter: rpazdera | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Stable Release
Component: lnst-ctl | Version: git
Keywords: | Blocked By:
Blocking: |
-------------------------+-----------------------------
The `NetTestController` class has got quite big over the last year of
development. There are lots of things mixed together, which makes it quite
hard to maintain.
This piece of code needs to be divided into several parts. The first stage
of this is to separate the routines that are tied to machine
initialisation to a new class -- `SlaveMachine`.
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/65>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
11 years
[lnst trac] #62: lnst-ctl error reporting doesn't work at all
by fedora-badges
#62: lnst-ctl error reporting doesn't work at all
----------------------+------------------
Reporter: rpazdera | Owner:
Type: defect | Status: new
Priority: blocker | Milestone:
Component: lnst-ctl | Version: git
Keywords: | Blocked By:
Blocking: |
----------------------+------------------
I have been working with `lnst-ctl` in a sort-of unusual way for the last
couple of days and what I discovered is, that if something goes wrong, the
controller will print a completely unrelated error message. This happens
in like 70% of cases. Usually, when the parser is involved.
We certainly need to be more careful in this aspect, because it could
seriously drive any potential users off.
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/62>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
11 years
[lnst trac] #61: Drop <machine_config> support in recipe files
by fedora-badges
#61: Drop <machine_config> support in recipe files
----------------------+------------------
Reporter: rpazdera | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: lnst-ctl | Version: git
Keywords: | Blocked By:
Blocking: |
----------------------+------------------
We have agreed recently to drop the support of `<machine_config>` in the
recipe files entirely. Instead, users should use only `<machinerequires>`
and set up a machine pool.
This should make things simpler and more clear. It will also force our
users to not ignore one of the key features of LNST - the abstraction
layer for networking infrastructure.
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/61>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
11 years, 1 month
[lnst trac] #56: Replace <info> tag with more generic <properties>
by fedora-badges
#56: Replace <info> tag with more generic <properties>
-------------------------+------------------
Reporter: rpazdera | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: lnst-ctl | Version: git
Keywords: | Blocked By:
Blocking: |
-------------------------+------------------
The info tag is not very scalable for the future. It should be replaced by
a <properties> tag, that will accept children -- one child per property.
Example:
<properties>
<property name="hostname" value="machine.redhat.com"/>
<property name="libvirt_domain" value="test_machine_1"/>
<property name="os" value="Fedora 18"/>
</property>
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/56>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
11 years, 1 month
[lnst trac] #60: Ambiguous <machine_config> tag
by fedora-badges
#60: Ambiguous <machine_config> tag
-------------------------+------------------
Reporter: rpazdera | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: lnst-ctl | Version: git
Keywords: | Blocked By:
Blocking: |
-------------------------+------------------
The name of `<machine_config>` tag might lead users that some
configuration takes place in the machine pool. However, the files within a
machine pool just contain information of the slave machines in question.
We should consider renaming it to something more appropriate.
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/60>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
11 years, 1 month
XML Format Changes Summary
by Radek Pazdera
Hello Everyone!
We discussed some changes to the XML format last week that we would
like to implement in the future. I am posting just a brief summary
here.
First, we will restructure the <machinerequires> tag in the recipe.
The new format should be as follows:
<machine id="sender">
<requirements> <!-- This used to be called <machinerequires> -->
<params> <!-- This tag replaces the old <info> -->
<param name="os" value="RHEL6"/>
<param name="arch" value="x86_64"/>
<param name="hostname" value="192.168.1.10"/>
<param name="libvirt_domain" value="virt_rhel6"/>
</params>
<netdevices>
<netdevice phys_id="dev-1" network="seg-1">
<params> <!-- Netdevices now have parameters -->
<param name="type" value="eth"/>
<param name="driver" value="e1000"/>
</params>
</netdevice>
<netdevice phys_id="dev-2" network="seg-1">
<params>
<param name="type" value="eth"/>
<param name="driver" value="e1000"/>
<param name="hwaddr" value="54:02:00:12:34:56"/>
</params>
</netdevice>
</netdevices>
</requirements>
<netconfig>
...
</netconfig>
</machine>
The other change occured in Machine Config XML format. We decided to
drop the 'machine config' name entirely and call it 'slave details'
or 'slave information' instead. The XML format has changed as well:
<!-- This used to be <machine_config> -->
<slavemachine>
<!-- This replaces the <info> tag -->
<params>
<param name="hostname" value="192.168.1.10"/>
<param name="rpcport" value="9999"/>
<param name="os" value="RHEL6"/>
<param name="arch" value="x86_64"/>
<param name="libvirt_domain" value="virt_rhel6"/>
</params>
<netdevices>
<netdevice phys_id="dev-2" network="test-1"
<params>
<param name="type" value="eth"/>
<param name="driver" value="e1000"/>
<param name="hwaddr" value="54:02:00:12:34:56"/>
</params>
</netdevice>
<netdevice phys_id="dev-2" network="test-1"
<params>
<param name="type" value="eth"/>
<param name="driver" value="e1000"/>
<param name="hwaddr" value="54:02:00:56:12:34"/>
</params>
</netdevice>
</netdevices>
</slavemachine>
I did some changes to the proposal we agreed on last week. We decided
to put the 'network' parameter of a netdevice to the <params> tag, but
it seems now, that it should rather be an attribute to the <netdevice>
tag instead.
All the values within the <params> tag are matched exactly as they are
written using the "==" operator (wich might be changed in the future to
a regexp match). The problem is the 'network' parameter is matched
differently. LNST controller will use a backtracking algorithm to
search the slave pool topology and form suitable pairs between phys_ids
and networks from the recipe and the pool.
So, for example, network "segment-1" can be matched to "test-53". This
migh be a little confusing for users, if we were to put it between the
parameters. The users might think, that they have to use the same name
for the networks in the recipe as they did in the pool.
Therefore, I decided to put 'network' as an attribute to th <netdevice>
tag.
Additionally, I moved the rpcport to the <params> tag. We originally
planed to put it as an attribute to <slavemachine>, because we don't
match against it. There is no reason to match against "rpcport", but
if you think about it, there is no reason to match against
'libvirt_domain' or 'hostname' either and they still are in the same
array.
With the new system of dynamic parameters, if you would like to get
a specific slave from the pool, you will be able to atually name it
(by adding <param name="name" value="peanut"/> and avoid using hard
to remember details such as IP address or libvirt domainname.
The second alternative is to add one more section to the
<slavemachine> tag called <config> to keep these internal details
(such as hostname, libvirt_domain, and rpcport). These would not be
used for matching.
The discussion about this is getting rather long and frustrating,
but I believe it is important to get it right. It will be much harder
to change these things as soon as we make a stable release.
Cheers
-Radek
11 years, 2 months
[lnst] TestIperf: bind option not specified bug
by Jiří Pírko
commit 2d7765cad0d30e83ffca61d309871da52dbfe091
Author: Ondrej Lichtner <olichtne(a)redhat.com>
Date: Fri Feb 8 11:09:49 2013 +0100
TestIperf: bind option not specified bug
When the module is run in the 'server' role and the option 'bind' is not
specified, the constructed command contains 'None' instead, creating an
invalid command.
This commit fixes that.
Signed-off-by: Ondrej Lichtner <olichtne(a)redhat.com>
test_modules/TestIperf.py | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/test_modules/TestIperf.py b/test_modules/TestIperf.py
index 0a9b047..462c48c 100644
--- a/test_modules/TestIperf.py
+++ b/test_modules/TestIperf.py
@@ -26,7 +26,10 @@ class TestIperf(TestGeneric):
cmd = "iperf --%s %s -t %s %s" % (role, iperf_server, self.duration, iperf_options)
elif role == "server":
bind = self.get_opt("bind", opt_type="addr")
- cmd = "iperf --%s -B %s %s" % (role, bind, iperf_options)
+ if bind != None:
+ cmd = "iperf --%s -B %s %s" % (role, bind, iperf_options)
+ else:
+ cmd = "iperf --%s %s" % (role, iperf_options)
return cmd
11 years, 2 months
[lnst] TestTCPListen: option parsing bug fixes
by Jiří Pírko
commit 9608692cc0d766a006638612f5386cdd99da8b87
Author: Ondrej Lichtner <olichtne(a)redhat.com>
Date: Fri Feb 8 11:09:48 2013 +0100
TestTCPListen: option parsing bug fixes
This commit fixes the same bug with the "port" option as in the
TestTCPConnect.
Signed-off-by: Ondrej Lichtner <olichtne(a)redhat.com>
test_modules/TestTCPListen.py | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
---
diff --git a/test_modules/TestTCPListen.py b/test_modules/TestTCPListen.py
index 3aa4d47..eb1697b 100644
--- a/test_modules/TestTCPListen.py
+++ b/test_modules/TestTCPListen.py
@@ -48,7 +48,7 @@ class TestTCPListen(TestGeneric):
# either port or port_range should be set
port = self.get_opt("port")
if port:
- self._port = port
+ self._port = int(port)
else:
port_range = self.get_opt("port_range")
if port_range:
@@ -169,7 +169,7 @@ class TestTCPListen(TestGeneric):
ports = []
if self._port:
- ports.extend(self._port)
+ ports.append(self._port)
else:
r = self._parse_port_range()
ports.extend(r)
11 years, 2 months