[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
[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
[IDEA] Drop <requirements> entirely
by Radek Pazdera
Hello everyone!
It occured to me, while I was refactoring the NetTestController that
some information in the recipe XMLs are duplicated.
We have <requirements> that contain information about the machine needed
by the matching algorithm and the rest of the configuration info is
filed under <netconfig>.
However, these two are very vaguely defined and the thing is, that the
contents of the <netdevices> tag can be determined from the contents of
the <netconfig> tag (if you are configuring an interface, you will
probably need a device for that).
My idea is, what would happen if we decided to merge these two things
together? There would be only a single description of the machine.
Here is an example of a current <machine> tag:
<machine id="1">
<requirements>
<params>
<param name="os" value="rhel6.2"/>
</params>
<netdevices>
<netdevice network="ttnet" phys_id="t1"/>
<netdevice network="ttnet" phys_id="t2"/>
</netdevices>
</requirements>
<netconfig>
<interface id="1" phys_id="t1" type="eth"/>
<interface id="2" phys_id="t2" type="eth"/>
<interface id="3" type="bond">
<slaves>
<slave id="1"/>
<slave id="2"/>
</slaves>
<addresses>
<address value="192.168.100.240/24"/>
</addresses>
</interface>
</netconfig>
</machine>
With the proposed changes things would look something like this:
<machine id="1">
<params>
<param name="os" value="rhel6.2"/>
</params>
<interfaces>
<interface id="1" network="ttnet" type="eth">
<params>
<param name="driver" value="virtio"/>
</params>
</interface>
<interface id="2" network="ttnet" type="eth"/>
<interface id="3" type="bond">
<options>
<option name="miimon" value="10">
</options>
<slaves>
<slave id="1"/>
<slave id="2"/>
</slaves>
<addresses>
<address value="192.168.100.240/24"/>
</addresses>
</interface>
</interfaces>
</machine>
Each interface type could have different subtags allowed (params,
addresses, slaves, or options). The controller would read only
interfaces of type="eth" and it would use them for matching.
This approach would be a complete abstraction of the machine. You just
specify a machine and LNST will take care of it automatically.
Alternatively, we could use different tags for each interface tag which
would make the <interfaces> tag could look like this:
<interfaces>
<eth id="1" network="ttnet">
<params>
<param name="driver" value="virtio"/>
</params>
</eth>
<eth id="2" network="ttnet"/>
<bond id="3">
<options>
<option name="miimon" value="10">
</options>
<slaves>
<slave id="1"/>
<slave id="2"/>
</slaves>
<addresses>
<address value="192.168.100.240/24"/>
</addresses>
</bond>
</interfaces>
In this case, it would be really clear that each tag can have different
children, so we wouldn't need to provide additional logic for resolving
conflicts and checking for all the obscure corner-cases.
What are your opinions on this? Any feedback appreciated :-).
Cheers
-Radek
11 years
[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
New way of splitting recipes into multiple files
by Radek Pazdera
Hello everyone!
We discussed a problem of splitting LNST recipes into multiple files.
This is, at the moment, supported by LNST in the form of source
attributes. If you'd like to put a part of your recipe to a different
file you can do this like this:
<machine source="abc.xml"/>
machine.xml:
<machine id="5">
...
</machine>
This works however the problem is it doesn't help with code duplication
because there is no (non-obscure) way of passing parameters to the
included file.
We discussed this and came up with the following proposal. We could
remove the source attribute completely and use a different tag called
'include' instead:
<include what="machine" source="abc.xml">
<options>
<option name="ip" value="192.168.1.2"/>
</options>
</include>
Includes like this one could have params/options child tag. These
parameters would then be defined as aliases in the included part of the
file.
A way to add parameters to included snippets woud allow us to reuse
different parts of the recipe for different purposes/machines. Now you
can split the file into multiple files, but if you have two machines
with exactly the same configuration and only different ip addresses, you
need to keep the config twice. That is really inefficient.
Anybody has any ideas/suggestions about this? I personally think, that
the <include> tag would be very useful, but I'm not really sure about
the format. It seems quite long to me. However, I'm not sure how to make
it shorter and still keep it nicely readable.
Cheers,
Radek
11 years
How to do this with lnst?
by Bill Peck
Hello,
First, I think this is a great project and think it has a lot of
potential. Second, I'm wondering if someone might be able to help me
model my current test cases in lnst. I'll include the job xml that I'm
currently using in beaker and try and break it down here.
The physical setup is between two real systems, and on each real system
is 3 virtual systems:
SystemA
rhel6u4_1
rhel6u4_2
rhel6u4_3
SystemB
rhel6u4_4
rhel6u4_5
rhel6u4_6
SystemA and SystemB have multiple network interfaces.
We want to test OpenVSwitch with the bnx2x driver and vlans.
My test plan does the following:
- Provision SystemA with RHEL6U4
- Install three virt guests
- Install openVswitch
- Configure ovsbridge1 using p2p1 (we know this is the bnx2x card), use
a local private ip address, also configure which trunks will support.
- Add the ovsbridge1 interface to rhel6u4_1,rhel6u4_2 with tag 100
- Add the ovsbridge1 interface to rhel6u4_3 with tag 200
- Start the virt guests with their new config. All guests will start
with eth0, and when running they will configure eth1
- From each guest ping the other guests, record pass/fail based on
whether you should have been able to or not.
- same test as previous but using netperf.
In parallel I do the same thing on SystemB.
SystemA interface p2p1 is connected through a private switch to SystemB
interface p2p1
This works but I am hard coded to using two hosts that I know are
configured the way I need. From looking at lnst it looks like this
could be done more dynamically. I did see some references to beaker
integration but I didn't see anything more.
Is this use case too complicated? Do you see subsets that could be
tackled now?
Any help would be appreciated. Thanks!
11 years
[lnst] NetTestParse: Fixing wrong node for exceptions
by Jiří Pírko
commit 1e0ec7b21500d70a6020d89630056fe67aa6e8f0
Author: Radek Pazdera <rpazdera(a)redhat.com>
Date: Thu Mar 14 13:13:56 2013 +0100
NetTestParse: Fixing wrong node for exceptions
This patch fixes a copy-paste error of XmlProcessingErrors in
NetTestParser. These exceptions were referencing xml_dom instead of
node.
Signed-off-by: Radek Pazdera <rpazdera(a)redhat.com>
lnst/Controller/NetTestParse.py | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/lnst/Controller/NetTestParse.py b/lnst/Controller/NetTestParse.py
index 6f7d901..caa15a0 100644
--- a/lnst/Controller/NetTestParse.py
+++ b/lnst/Controller/NetTestParse.py
@@ -172,7 +172,7 @@ class MachineParse(RecipeParser):
try:
self._trigger_event("machine_ready", {"machine_id": self._id})
except Exception as exc:
- logging.error(XmlProcessingError(str(exc), xml_dom))
+ logging.error(XmlProcessingError(str(exc), node))
raise
class ParamsParse(RecipeParser):
@@ -330,7 +330,7 @@ class SlaveMachineParse(RecipeParser):
self._trigger_event("netdevice_ready",
{"machine_id": self._machine_id, "dev_id": phys_id})
except Exception as exc:
- logging.error(XmlProcessingError(str(exc), xml_dom))
+ logging.error(XmlProcessingError(str(exc), node))
raise
class NetConfigParse(RecipeParser):
@@ -387,7 +387,7 @@ class NetConfigParse(RecipeParser):
except Exception as exc:
msg = "Unable to configure interface %s on machine %s [%s]." % \
(dev_id, self._machine_id, str(exc))
- logging.error(XmlProcessingError(str(msg), xml_dom))
+ logging.error(XmlProcessingError(str(msg), node))
raise
def _process_phys_id_attr(self, node, dev):
11 years
[lnst] NetTestParse: Fixing a bug with params parsing
by Jiří Pírko
commit 0fdcf424e0a9c3ca9b8f0063d79128a618f6cfcb
Author: Radek Pazdera <rpazdera(a)redhat.com>
Date: Thu Mar 14 12:12:52 2013 +0100
NetTestParse: Fixing a bug with params parsing
At the moment, lnst-ctl drops dead when you specify some parameters
in the requirements for the devices.
This patch fixes it.
Signed-off-by: Radek Pazdera <rpazdera(a)redhat.com>
lnst/Controller/NetTestParse.py | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
---
diff --git a/lnst/Controller/NetTestParse.py b/lnst/Controller/NetTestParse.py
index 430c033..6f7d901 100644
--- a/lnst/Controller/NetTestParse.py
+++ b/lnst/Controller/NetTestParse.py
@@ -230,10 +230,10 @@ class RequirementsParse(RecipeParser):
scheme = {"params": self._params}
params = {"target": dev["params"]}
- self._process_child_nodes(node, scheme)
+ self._process_child_nodes(node, scheme, params)
if "type" in dev["params"]:
- dev["type"] = self._get_attribute(node, "type")
+ dev["type"] = dev["params"]["type"]
if "hwaddr" in dev["params"]:
dev["hwaddr"] = normalize_hwaddr(dev["params"]["hwaddr"])
11 years
[lnst] XmlTemplates: Bug in alias processing
by Jiří Pírko
commit 09bc022f312f607ec1b0e32d77543904ba32355e
Author: Radek Pazdera <rpazdera(a)redhat.com>
Date: Thu Mar 14 12:08:37 2013 +0100
XmlTemplates: Bug in alias processing
There was a bug causing a stack trace in the alias processing code in
XmlTemplates. And it actually appears it was there unnoticed for quite
a few months.
This patch fixes that.
Signed-off-by: Radek Pazdera <rpazdera(a)redhat.com>
lnst/Common/XmlTemplates.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/lnst/Common/XmlTemplates.py b/lnst/Common/XmlTemplates.py
index 26db78a..29d90d9 100644
--- a/lnst/Common/XmlTemplates.py
+++ b/lnst/Common/XmlTemplates.py
@@ -172,7 +172,7 @@ class XmlTemplates:
alias_match = re.match(self._alias_re, string)
if alias_match:
alias_name = alias_match.group(1)
- alias_obj = self._find_definition(alias_name)
+ result = self._find_definition(alias_name)
return result
11 years