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
Thu, Mar 21, 2013 at 02:52:50PM CET, rpazdera@redhat.com wrote:
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>
I would go with this one.
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>
IMHO this might be confusing because we would use uniqueue id for multiple tags...
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 _______________________________________________ LNST-developers mailing list LNST-developers@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/lnst-developers
lnst-developers@lists.fedorahosted.org