7:21 a.m.
Mon, Feb 11, 2013 at 02:00:34PM CET, rpazdera(a)redhat.com wrote:
Hello Everyone!
We discussed some changes to the XML format last week that we would
like to implement in the future. I am posting just a brief summary
here.
First, we will restructure the <machinerequires> tag in the recipe.
The new format should be as follows:
<machine id="sender">
<requirements> <!-- This used to be called <machinerequires>
-->
<params> <!-- This tag replaces the old <info> -->
<param name="os" value="RHEL6"/>
<param name="arch" value="x86_64"/>
<param name="hostname" value="192.168.1.10"/>
<param name="libvirt_domain"
value="virt_rhel6"/>
</params>
<netdevices>
<netdevice phys_id="dev-1" network="seg-1">
<params> <!-- Netdevices now have parameters -->
<param name="type" value="eth"/>
<param name="driver" value="e1000"/>
</params>
</netdevice>
<netdevice phys_id="dev-2" network="seg-1">
<params>
<param name="type" value="eth"/>
<param name="driver" value="e1000"/>
<param name="hwaddr"
value="54:02:00:12:34:56"/>
</params>
</netdevice>
</netdevices>
</requirements>
<netconfig>
...
</netconfig>
</machine>
The other change occured in Machine Config XML format. We decided to
drop the 'machine config' name entirely and call it 'slave details'
or 'slave information' instead. The XML format has changed as well:
<!-- This used to be <machine_config> -->
<slavemachine>
<!-- This replaces the <info> tag -->
<params>
<param name="hostname" value="192.168.1.10"/>
<param name="rpcport" value="9999"/>
<param name="os" value="RHEL6"/>
<param name="arch" value="x86_64"/>
<param name="libvirt_domain" value="virt_rhel6"/>
</params>
<netdevices>
<netdevice phys_id="dev-2" network="test-1"
<params>
<param name="type" value="eth"/>
<param name="driver" value="e1000"/>
<param name="hwaddr"
value="54:02:00:12:34:56"/>
</params>
</netdevice>
<netdevice phys_id="dev-2" network="test-1"
<params>
<param name="type" value="eth"/>
<param name="driver" value="e1000"/>
<param name="hwaddr"
value="54:02:00:56:12:34"/>
</params>
</netdevice>
</netdevices>
</slavemachine>
I did some changes to the proposal we agreed on last week. We decided
to put the 'network' parameter of a netdevice to the <params> tag, but
it seems now, that it should rather be an attribute to the <netdevice>
tag instead.
All the values within the <params> tag are matched exactly as they are
written using the "==" operator (wich might be changed in the future to
a regexp match). The problem is the 'network' parameter is matched
differently. LNST controller will use a backtracking algorithm to
search the slave pool topology and form suitable pairs between phys_ids
and networks from the recipe and the pool.
So, for example, network "segment-1" can be matched to "test-53".
This
migh be a little confusing for users, if we were to put it between the
parameters. The users might think, that they have to use the same name
for the networks in the recipe as they did in the pool.
Therefore, I decided to put 'network' as an attribute to th <netdevice>
tag.
sounds reasonable, I agree.
Additionally, I moved the rpcport to the <params> tag. We originally
planed to put it as an attribute to <slavemachine>, because we don't
match against it. There is no reason to match against "rpcport", but
if you think about it, there is no reason to match against
'libvirt_domain' or 'hostname' either and they still are in the same
array.
With the new system of dynamic parameters, if you would like to get
a specific slave from the pool, you will be able to atually name it
(by adding <param name="name" value="peanut"/> and avoid using
hard
to remember details such as IP address or libvirt domainname.
The second alternative is to add one more section to the
<slavemachine> tag called <config> to keep these internal details
(such as hostname, libvirt_domain, and rpcport). These would not be
used for matching.
Second aproach seems more right to me. Why to make it possible to match
agains something which does not make senso to do so. Config element for
actual these kind of info seems ok.
The discussion about this is getting rather long and frustrating,
but I believe it is important to get it right. It will be much harder
to change these things as soon as we make a stable release.
Cheers
-Radek
_______________________________________________
LNST-developers mailing list
LNST-developers(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/lnst-developers