[Fusioninventory-devel] Confusion between network interfaces and network addresses

[Guillaume Rousse]

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