While reviewing yesterday changes from Goneri, I found there was some
confusion in our code between two different concepts: network interfaces
and network addresses. Worse, we are not even consistent among the
various OS, most notably between Linux and Windows.
Let's consider a machine with two interfaces, one active with two
attached addresses, and one inactive.
Strategy 1:
In Windows code, as seen in the t/inventory/windows/networks.t expected
results, a 'networks' entry is strictly a network interface. The example
scenario would result into the following internal representation:
{
description => 'foo',
ipaddress => [ '127.0.0.1', '127.0.0.2' ],
ipmask => [ '255.0.0.0', '255.0.0.0' ]
},
{
description => 'bar',
status => 'down'
}
Which translates into the following XML result with multiple elements of
the same name:
<NETWORKS>
<DESCRIPTION>foo</DESCRIPTION>
<IPADDRESS>127.0.0.1</IPADDRESS>
<IPADDRESS>127.0.0.2</IPADDRESS>
<IPMASK>255.0.0.0</IPMASK>
<IPMASK>255.0.0.0</IPMASK>
</NETWORKS>
<NETWORKS>
<DESCRIPTION>bar</DESCRIPTION>
<STATUS>down</STATUS>
</NETWORKS>
Advantage: consistent nature of 'networks' entries
Inconvients: less relationship between each address components (address,
mask, subnet)
Strategy 2:
In Linux code, at least for /sbin/ip parsing, a networks entry is either
a single network address, or a network interfaces (for interfaces
without attached addresses), as can be seen from expected results from
t/tools/linux.t. The example scenario would result into the following
internal representation:
{
description => 'foo',
ipaddress => '127.0.0.1',
ipmask => '255.0.0.0',
},
{
description => 'foo',
ipaddress => '127.0.0.2',
ipmask => '255.0.0.0'
},
{
description => 'bar',
status => 'down'
}
and the following XML representation:
<NETWORKS>
<DESCRIPTION>foo</DESCRIPTION>
<IPADDRESS>127.0.0.1</IPADDRESS>
<IPMASK>255.0.0.0</IPMASK>
</NETWORKS>
<NETWORKS>
<DESCRIPTION>foo</DESCRIPTION>
<IPADDRESS>127.0.0.2</IPADDRESS>
<IPMASK>255.0.0.0</IPMASK>
</NETWORKS>
<NETWORKS>
<DESCRIPTION>bar</DESCRIPTION>
<STATUS>down</STATUS>
</NETWORKS>
We now have three objects instead of two for the same configuration...
Advantage: strict relationship between each address components (address,
mask, subnet)
Inconvients: inconsistent nature of 'networks' entries
Alternative representations:
Strategy 3:
We could consider network addresses only, but we would loose interfaces
without attached addresses:
{
description => 'foo',
ipaddress => '127.0.0.1',
ipmask => '255.0.0.0',
},
{
description => 'foo',
ipaddress => '127.0.0.2',
ipmask => '255.0.0.0'
}
<NETWORKS>
<DESCRIPTION>foo</DESCRIPTION>
<IPADDRESS>127.0.0.1</IPADDRESS>
<IPMASK>255.0.0.0</IPMASK>
</NETWORKS>
<NETWORKS>
<DESCRIPTION>foo</DESCRIPTION>
<IPADDRESS>127.0.0.2</IPADDRESS>
<IPMASK>255.0.0.0</IPMASK>
</NETWORKS>
Advantages:
- strict relationship between each address components (address, mask,
subnet)
- consistent nature of 'networks' entries
Inconvients: loss of unactives interfaces
Strategy 4:
We could also keep the network-only representation with multivalued
attributes of Windows code, but flattening the XML result:
<NETWORKS>
<DESCRIPTION>foo</DESCRIPTION>
<IPADDRESS>127.0.0.1,127.0.0.2</IPADDRESS>
<IPMASK>255.0.0.0, 255.0.0.0</IPMASK>
</NETWORKS>
<NETWORKS>
<DESCRIPTION>bar</DESCRIPTION>
<STATUS>down</STATUS>
</NETWORKS>
Advantage: consistent nature of 'networks' entries
Inconvients:
- less relationship between each address components (address, mask, subnet)
- less structured result (parsing would have to be done server-side)
Strategy 5:
Last option, use a structured representation closer to the actual
concepts relationship, but it would be hard to translate into an XML
format without breaking OCS compatibility:
{
description => 'foo',
addresses => [
{
ipaddress => '127.0.0.1',
ipmask => '255.0.0.0',
},
{
ipaddress => '127.0.0.2',
ipmask => '255.0.0.0'
}
],
},
{
description => 'bar',
status => 'down'
}
<NETWORKS>
<DESCRIPTION>foo</DESCRIPTION>
<ADDRESS>
<IPADDRESS>127.0.0.1</IPADDRESS>
<IPMASK>255.0.0.0</IPMASK>
</ADDRESS>
<ADDRESS>
<IPADDRESS>127.0.0.2</IPADDRESS>
<IPMASK>255.0.0.0</IPMASK>
</ADDRESS>
</NETWORKS>
<NETWORKS>
<DESCRIPTION>bar</DESCRIPTION>
<STATUS>down</STATUS>
</NETWORKS>
I think we all agree we should enforce a consistent strategy everywhere.
My favorite ones would be 1, then 3, then 2. mainly because I prefer the
idea of having all 'networks' entries corresponding to a single concept,
rather than the idea of mixing concepts just for practical advantage.
--
BOFH excuse #334:
50% of the manual is in .pdf readme files
_______________________________________________
Fusioninventory-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel
