[Fusioninventory-devel] network inventory: adding default values in the agent

[Guillaume Rousse]

Hello.

I just uploaded here a summary on the impact of changes brought by the 
model+no_model_inventory branch on our test database:
http://www.zarb.org/~guillomovitch/report.html

Basically, this branch just provides default values for most generic and 
network-device-specific mappings, never overriding model value if 
available. For instance:
my $vlanStatus = $snmp->walk(
     $model->{oids}->{vlanTrunkPortDynamicStatus} ||
     '.1.3.6.1.4.1.9.9.46.1.6.1.1.14'
);

Foreach test sample, the 'changes' columns gives a quick summary of the 
changes in the agent output between the 'master' branch and the results 
of the 'master+no_model_inventory' branch (for a detailed summary, just 
run git diff master+no_model_inventory t/agent/tools/hardware/foo.t). 
And the 'reasons' columns tries to provide an explanation for those changes.

The most obvious result, is whereas the expected output for any device 
without any SNMP model affected was almost empty, we now have an almost 
complete result (at least for network devices, printers-specific values 
are more difficult to identify). For instance, see Extreme devices: 
we're going from 'no result at all' to 'results everywhere'.

This also make failing to identify proper model less devastating. See 
for instance the Xerox Phase 8560DN serie, where all samples get a 
model, excepted Phaser_8560DN.12, just because a minor difference in its 
sysdescr value: we still get most values.

But, and this will be my main point, is also show than most of the 
models are at least incomplete, and lacks either trivial (uptime) or 
critical (dot1dBasePortIfIndex) mappings, even when we tought we had a 
good support, such as Cisco device: on 35 tests samples, and 13 
different models, I found only one model (Networking2034) for which I 
couldn't find missing mappings...

Of course, some of the added values may be erroneous (notably, I found 
some memory = 0 results), and would requires additional filtering. But 
nothing significantly wrong.

I'm planning to merge this branch into master, unless we found evidences 
of opposite side-effects.
-- 
Guillaume