[PATCH] Add attribute to explicitly disable cleanup on slave
by Jan Tluka
This patch adds "skip_cleanup" attribute to the machineconfig's info tag.
If set to "1" or "true" the slave machine's preparation cleanup phase is
skipped and overrides the cleanup (-c) controller option.
Without this attribute it's impossible to run the controller and slave
instances on the same machine with virtual guests or 8021q/bonding/team
driver involved because the cleanup phase removes these network modules
before test execution and breaks the controller's network configuration.
Signed-off-by: Jan Tluka <jtluka(a)redhat.com>
---
lnst/Controller/NetTestController.py | 4 +++-
lnst/Controller/NetTestParse.py | 6 ++++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/lnst/Controller/NetTestController.py b/lnst/Controller/NetTestController.py
index d673822..042d197 100644
--- a/lnst/Controller/NetTestController.py
+++ b/lnst/Controller/NetTestController.py
@@ -254,8 +254,10 @@ class NetTestController:
self._rpc_call(machine_id, "clear_resource_table")
required = self._resource_table
- if self._docleanup:
+ if self._docleanup and not info["skip_cleanup"]:
self._rpc_call(machine_id, 'machine_cleanup')
+ else:
+ logging.info("Skipping cleanup on machine %s" % machine_id)
for res_type, resources in self._resource_table.iteritems():
for res_name, res in resources.iteritems():
diff --git a/lnst/Controller/NetTestParse.py b/lnst/Controller/NetTestParse.py
index 3a24faf..28fe9ed 100644
--- a/lnst/Controller/NetTestParse.py
+++ b/lnst/Controller/NetTestParse.py
@@ -288,6 +288,12 @@ class MachineConfigParse(RecipeParser):
if self._has_attribute(node, "rpcport"):
info["rpcport"] = self._get_attribute(node, "rpcport", int)
+ if self._has_attribute(node, "skip_cleanup"):
+ info["skip_cleanup"] = self._get_attribute(node,
+ "skip_cleanup", bool_it)
+ else:
+ info["skip_cleanup"] = False
+
info["system_config"] = {}
try:
--
1.7.7.6
11 years, 4 months
Documentation Roadmap
by Radek Pazdera
Hi!
Let me just quickly sum up, what did we agree upon in today's meeting.
I actually added a few points there, so please object if you don't
agree with something!
The documentation should have the following structure:
1. About LNST
- this should be a complete overview of what lnst is capable of
- it could be derived from the existing LNSTIntro from Honza
2. Deploying LNST
2.1 Installation Guide
- There should be a guide for both package and from-source
installation methods
- already done
2.2 Set Up Your Machine Pool
- How to prepare slave machines for testing
- It should be almost done
2.3 LNST Configuration
- Where are the configuration files
- Format Description
- What options are accepted
3. Testing With LNST
3.1 How To Structure LNST Recipes
- Comprehensive guide for inexperienced users
- How to create a recipe?
- What are the best practices?
- This should be based on Chapter 4 of LNSTIntro
3.2 LNST Invocation
- Just a brief how-to run lnst
- What are recipe sets, how to run batch recipes
- Describe the behaviour of LNST in case of a single test/recipe
failure within a recipe set. What will happen?
3.2 Test Results
- Where are they?
- What is the format?
4. Advanced Topics
4.1 Making Your Own Test Module
4.2 Using Third-Party Tools With LNST
4.3 Virtualization With LNST
4.4 Beaker Integration
Hopefully this covers everything important. I have already created some
stubs for the pages and the index on the main page.
Cheers,
Radek
11 years, 4 months
Re: [lnst trac] #40: Doc: Recipe XML Format Reference on Wiki
by fedora-badges
#40: Doc: Recipe XML Format Reference on Wiki
-------------------------+-----------------------------------------
Reporter: rpazdera | Owner: somebody
Type: task | Status: new
Priority: major | Milestone: Complete Wiki Documentation
Component: component1 | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
-------------------------+-----------------------------------------
Changes (by rpazdera):
* milestone: Push LNST as a package into Fedora => Complete Wiki
Documentation
Old description:
> There should be a detailed recipe format reference/guide for users to
> learn what options do they have.
>
> This could be also a good documentation for us.
New description:
There should be a detailed recipe format reference/guide for users to
learn what options do they have.
This could be also a good documentation for us.
This article should be brief and to point. It should cover just the basic
syntax without any howto's. This has to be a complete and exhaustive
reference for the experienced user to refer to in case of doubt over a
name of a tag.
--
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/40#comment:2>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
11 years, 4 months
[lnst trac] #47: lnst-slave crashes on modules/tools sync with ctl
by fedora-badges
#47: lnst-slave crashes on modules/tools sync with ctl
------------------------+-------------------------------------------------
Reporter: rpazdera | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: Push LNST as a package into Fedora
Component: component1 | Version:
Keywords: | Blocked By:
Blocking: |
------------------------+-------------------------------------------------
lnst-slave will crash when it tries to write data data to cache and a
directory with the respective name already exists. This can happen for
instance when lnst-slave was interrupted in the middle of the file
transfer from ctl to cache in a previous run (and therefore the index was
not committed properly).
The expected behaviour is to remove any unexpected data from cache and
continue loading new files WITHOUT a crash :).
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/47>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
11 years, 4 months
Exec on controller revisited
by Jan Tluka
Hi guys,
we have recently removed possibility to run exec command on the
controller itself. The argument was that if someone needs to do such
thing he should start slave instance on the controller. This is ok and
makes sense. However, there's one problem. It's the cleanup phase. I'm
using virtual guests as test machines and controller is run from host.
I need to add netem on the host bridge to simulate packet loss and
reordering. So I started lnst-slave on the controller but oops, the
bridge went down because bridge module is removed in the cleanup phase.
So, here's the proposal. I'd like to add "module_cleanup" attribute to
machineconfig info tag. If it's set to "no" the cleanup phase won't be
executed even if user passes -c option to the controller.
Let me know if this makes sense or if you see different approach to this
case.
Thanks
-Jan
11 years, 4 months
[PATCH] Add attribute to explicitly disable cleanup on slave
by Jan Tluka
This patch adds "machine_cleanup" attribute to the machineconfig's info tag.
If set to "no" the slave machine's preparation cleanup phase is skipped
and overrides the cleanup (-c) controller option.
Without this attribute it's impossible to run the controller and slave
instances on the same machine with virtual guests or 8021q/bonding/team
driver involved because the cleanup phase removes these network modules
before test execution and breaks the controller's network configuration.
Signed-off-by: Jan Tluka <jtluka(a)redhat.com>
---
lnst/Controller/NetTestController.py | 9 ++++++++-
lnst/Controller/NetTestParse.py | 4 ++++
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/lnst/Controller/NetTestController.py b/lnst/Controller/NetTestController.py
index d673822..9570990 100644
--- a/lnst/Controller/NetTestController.py
+++ b/lnst/Controller/NetTestController.py
@@ -255,7 +255,14 @@ class NetTestController:
required = self._resource_table
if self._docleanup:
- self._rpc_call(machine_id, 'machine_cleanup')
+ skip_cleanup = False
+ if "machine_cleanup" in info:
+ # cleanup for the machine is explicitly disabled
+ skip_cleanup = (info["machine_cleanup"] == "no")
+ if skip_cleanup:
+ logging.info("Skipping cleanup on machine %s" % machine_id)
+ else:
+ self._rpc_call(machine_id, 'machine_cleanup')
for res_type, resources in self._resource_table.iteritems():
for res_name, res in resources.iteritems():
diff --git a/lnst/Controller/NetTestParse.py b/lnst/Controller/NetTestParse.py
index 3a24faf..82dbf12 100644
--- a/lnst/Controller/NetTestParse.py
+++ b/lnst/Controller/NetTestParse.py
@@ -288,6 +288,10 @@ class MachineConfigParse(RecipeParser):
if self._has_attribute(node, "rpcport"):
info["rpcport"] = self._get_attribute(node, "rpcport", int)
+ if self._has_attribute(node, "machine_cleanup"):
+ info["machine_cleanup"] = self._get_attribute(node,
+ "machine_cleanup")
+
info["system_config"] = {}
try:
--
1.7.7.6
11 years, 4 months
[lnst trac] #48: Slave-side logging dir structure
by fedora-badges
#48: Slave-side logging dir structure
------------------------+-------------------------------------------------
Reporter: rpazdera | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: Push LNST as a package into Fedora
Component: component1 | Version:
Keywords: | Blocked By:
Blocking: |
------------------------+-------------------------------------------------
When lnst-slave runs as slave (i.e. doesn't get restarted for each recipe)
there is a possibility of collisions in logs, because only one time folder
is created.
The structure is following:
{{{<time>/<recipe_name>/...}}}
So if one recipe is executed twice, both logs will be written to the same
directory (and actually appended to the logs from previous run). That is,
in my opinion, rather unexpected.
Also multiple recipes of the same name executed within a single recipe set
will cause collisions in logging as well!
--
Ticket URL: <https://fedorahosted.org/lnst/ticket/48>
lnst <https://fedorahosted.org/lnst/>
Linux Network Stack Test
11 years, 4 months