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

[Arnaud Quette]

Hey Fusioners,

2012/4/5 Guillaume Rousse <guillomovitch at gmail.com>

> Le 05/04/2012 20:04, Guillaume Rousse a écrit :
>
>  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)
>>
> I just found out I was wrong, as ip_addr-2 sample shows an interface with
> two different IPv4 addresses:
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_**UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
>    link/ether 0f:0f:0f:0f:0f:0f brd ff:ff:ff:ff:ff:ff
>    inet 11.11.11.11/25 brd 11.11.11.127 scope global eth0
>    inet 172.16.0.201/17 brd 172.16.127.255 scope global eth0
>
> Let's forget my last proposition then :(
>

here is my 2 cents to the discussion (just remember that I'm very new to
FI!):
- I fully agree with the need of enforcing the network strategy.
Network info are the core relationships between devices, and their
accessibility from FI server.
- part of this enforcement, you should ensure that your model is bullet
proof solid for the decade to come.
Thus, it should cover past, current and possible future needs (Ie, be
generic and extensible enough).
This also means that your internal representation can't map 1/1 with OCS
(at least the current model)!
- I would vote for prop. 5, since it's the best one to model multi IP
addresses per interface.
- an adapter to OCS compatible XML should not be that hard, but not
directly bijective.
- having an interface type would be nice (ethernet, wifi, fiber, ...)
- the corollary is an address type (MAC, IP v4 / v6)
- thus, storing the MAC address also makes senses.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/fusioninventory-devel/attachments/20120406/4fdb8801/attachment.html>