Hey Fusioners,<br><br><div class="gmail_quote">2012/4/5 Guillaume Rousse <span dir="ltr"><<a href="mailto:guillomovitch@gmail.com">guillomovitch@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le 05/04/2012 20:04, Guillaume Rousse a écrit :<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le 05/04/2012 10:56, Gonéri Le Bouder a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello all,<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think we all agree we should enforce a consistent strategy<br>
everywhere. My<br>
favorite ones would be 1, then 3, then 2. mainly because I prefer the<br>
idea<br>
of having all 'networks' entries corresponding to a single concept,<br>
rather<br>
than the idea of mixing concepts just for practical advantage.<br>
</blockquote>
<br>
<br>
OCS uses the second solution, and we are supposed to follow this<br>
structure for<br>
the moment.<br>
This is design problem with IPv6, since it's now common to see one<br>
interface with<br>
various IPv6 configuration.<br>
</blockquote>
I missed the fact that actually, only IPv6 is concerned with multiple<br>
addresses with the same interface names (multiple IPv4 ones usually use<br>
different interfaces aliases)<br>
</blockquote></div>
I just found out I was wrong, as ip_addr-2 sample shows an interface with two different IPv4 addresses:<br>
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_<u></u>UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000<br>
link/ether 0f:0f:0f:0f:0f:0f brd ff:ff:ff:ff:ff:ff<br>
inet <a href="http://11.11.11.11/25" target="_blank">11.11.11.11/25</a> brd 11.11.11.127 scope global eth0<br>
inet <a href="http://172.16.0.201/17" target="_blank">172.16.0.201/17</a> brd 172.16.127.255 scope global eth0<br>
<br>
Let's forget my last proposition then :(<span class="HOEnZb"><font color="#888888"></font></span><br clear="all"></blockquote></div><br>here is my 2 cents to the discussion (just remember that I'm very new to FI!):<br>
- I fully agree with the need of enforcing the network strategy.<br>Network info are the core relationships between devices, and their accessibility from FI server.<br>- part of this enforcement, you should ensure that your model is bullet proof solid for the decade to come.<br>
Thus, it should cover past, current and possible future needs (Ie, be generic and extensible enough).<br>This also means that your internal representation can't map 1/1 with OCS (at least the current model)!<br>- I would vote for prop. 5, since it's the best one to model multi IP addresses per interface.<br>
- an adapter to OCS compatible XML should not be that hard, but not directly bijective.<br>- having an interface type would be nice (ethernet, wifi, fiber, ...)<br>- the corollary is an address type (MAC, IP v4 / v6)<br>- thus, storing the MAC address also makes senses.<br>
<br>cheers,<br>Arnaud<br>-- <br>Linux / Unix Expert R&D - Eaton - <a href="http://powerquality.eaton.com" target="_blank">http://powerquality.eaton.com</a><br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org/" target="_blank">http://www.networkupstools.org/</a><br>
Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>Free Software Developer - <a href="http://arnaud.quette.free.fr/" target="_blank">http://arnaud.quette.free.fr/</a><br><br>