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
_______________________________________________
Fusioninventory-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel
