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.
What do you think?
-Radek
Tue, Sep 25, 2012 at 06:54:18PM CEST, rpazdera@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/lnst-developers
lnst-developers@lists.fedorahosted.org