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

[Guillaume Rousse]

Le 05/04/2012 10:56, Gonéri Le Bouder a écrit :
> Hello all,
>
>> 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.
>
>
> OCS uses the second solution, and we are supposed to follow this structure for
> the moment.
> This is design problem with IPv6, since it's now common to see one
> interface with
> various IPv6 configuration.
I missed the fact that actually, only IPv6 is concerned with multiple 
addresses with the same interface names (multiple IPv4 ones usually use 
different interfaces aliases), and only for different classes of 
addresses (link vs global).

Given than they are different attributes for IPv6 and IPv4 addresses, 
and given there is no formal description of how the OCS server handle 
the result, I'd say than only reporting the global IPv6 addresses (the 
routable ones) would allow to keep strict relationship between network 
entries and network addresses.

Given the following scenario:
- active eth0 interface, with
  * IPv4 address A
  * global IPv6 address AAAA
  * local IPv6 address BBBB
- unactive eth1 interface

This would result into the following structure:
{
   description => 'eth0',
   status      => 'up',
   ipaddress   => 'A',
   ipmask      => 'a',
   ipaddress6  => 'AAAA',
   ipmask6     => 'aaaa',
},
{
   description => 'eth1',
   status      => 'down'
}
and the following XML representation:
<NETWORKS>
   <DESCRIPTION>eth0</DESCRIPTION>
   <STATUS>up</STATUS>
   <IPADDRESS>A</IPADDRESS>
   <IPMASK>a</IPMASK>
   <IPADDRESS6>AAAA</IPADDRESS6>
   <IPMASK6>aaaa</IPMASK6>
</NETWORKS>
<NETWORKS>
   <DESCRIPTION>eth1</DESCRIPTION>
   <STATUS>down</STATUS>
</NETWORKS>

Actually, this solution allows to make the work easier in our own server 
(one entry = one interface), and is probably also the closest for OCS 
behaviour (figuring they have consistent behaviour between 
implementations), at the only cost of excluding IPv6 link addresses. But 
given we were not even reporting them earlier, this seems to be quite 
minor problem.

-- 
The amount of time you spend getting ready for a date is inversely 
proportional to how well it will turn out.
		-- Principle of Diminishing Returns