Tue, Sep 25, 2012 at 06:54:18PM CEST, rpazdera(a)redhat.com wrote:
Hi!
I'm currently working on incorporating the matching algorithm code (more
precisely a class) into LNST. I had to modify some parts of
NetTestParser, but I have those parts basically ready.
The matching algorithm is already wrapped-up in a class and ready as
well. But I can't figure out how to work with the matched ID's.
When a template topology's been successfully matched, we need to take
the <machineconfig>'s and put it into the recipe in place of the
teplates. But there will be different phys_id's, so we need to change
them somehow.
We could replace them according to the matches, but it turns
out we can't do that so easily :(. In case of a successful partial
match, there could be conflicts between id's from template namespace
and pool namespace. To illustrate this, let's match a template A on a
machine B:
* template A with 2 interfaces, id's 1 and 2
* pool machine B with 3 interfaces, id's 1, 2, 3
They could be matched like this:
A B
----- -----
1 --> 3
2 --> 2
unused 1
In this case, after replacing matched id's we'd get a machine with
devices 1,1,2.
One is unused, so we could just remove it, but I don't think it's a
good idea. If the device is unused for testing (not referenced from
the <netconfig>), LNST should make sure it is DOWN, so it cannot
affect the test results in some very obscure way.
We could also do it the other way around. Replace the references to
phys_id in <netconfig>'s. But that could be a little confusing at
times. In case the values are ever used for error reporting.
In my opinion, the best way would be to count in both id's and somehow
work with them both. Maybe create some abstract type for id? I don't
know ... But it's hard to do such changes to the structure of the recipe
variable, because it is used on many places across a lot of modules.
I think that phys_ids in template should be internaly (after parse)
changed to some meaningless hash or something. They have no direct
meaning so why to let them confuse us? This resolves your problem with
duplicates. Or did I miss something?
Jiri
What do you think?
-Radek
_______________________________________________
LNST-developers mailing list
LNST-developers(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/lnst-developers