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

[Gonéri Le Bouder]

On Sat, Apr 07, 2012 at 09:35:38AM +0200, Stéphane Urbanovski wrote:
> Le 05/04/2012 09:42, Guillaume Rousse a écrit :
Hi Stéphane,

Today, an FusionInventory XML is a list of various different data structure:
  -ACCESSLOG
  -ANTIVIRUS
  -BATTERIES
  -BIOS
  -CONTROLLERS
  -CPUS
  -DRIVES
  -ENVS
  -HARDWARE
  -INPUTS
  -LOGICAL_VOLUMES
  -MEMORIES
  -MODEMS
  -MONITORS
  -NETWORKS
  -OPERATINGSYSTEM
  -PHYSICAL_VOLUMES
  -PORTS
  -PRINTERS
  -PROCESSES
  -REGISTRY
  -SLOTS
  -SOFTWARES
  -SOUNDS
  -STORAGES
  -USBDEVICES
  -USERS
  -VIDEOS
  -VIRTUALMACHINES
  -VOLUME_GROUPS

Each data structure has got its own key/value list of parameters. A value is always
a scalar (string). It's never another data structure.

For example:
    <CONTROLLERS>
      <CAPTION>Core Processor Reserved</CAPTION>
      <MANUFACTURER>Intel Corporation</MANUFACTURER>
      <NAME>Core Processor Reserved</NAME>
      <PCICLASS>0600</PCICLASS>
      <PCIID>8086:2d13</PCIID>
      <PCISLOT>ff:02.3</PCISLOT>
      <REV>02</REV>
      <TYPE>Host bridge</TYPE>
    </CONTROLLERS>
    <CPUS>
      <CORE>2</CORE>
      <MANUFACTURER>Intel</MANUFACTURER>
      <NAME>Intel(R) Core(TM) i3 CPU       M 350  @ 2.27GHz</NAME>
      <SPEED>2270</SPEED>
      <THREAD>2</THREAD>
    </CPUS>
    <DRIVES>
      <FILESYSTEM>rootfs</FILESYSTEM>
      <FREE>59556</FREE>
      <TOTAL>152420</TOTAL>
      <TYPE>/</TYPE>
      <VOLUMN>rootfs</VOLUMN>
    </DRIVES>
    <DRIVES>
      <FILESYSTEM>devtmpfs</FILESYSTEM>
      <FREE>3862</FREE>
      <TOTAL>3862</TOTAL>
      <TYPE>/dev</TYPE>
      <VOLUMN>udev</VOLUMN>
    </DRIVES>

This structure is inherited from OCS Inventory and has some limitation. Network
bonding is a good example of something hard to describe.

I understand your point of view and I think we all agree to say standard must to be
used as much as possible.
If we go for a DMTF/CIM format, we will have to change a lot the inventory structure
and increase its complexity.
Such changes will also force the servers to update their agent interfaces.

>From my point of view, for the moment there is no serious limitation with
the current section/key/value format and we can continue to deal with them.

This doesn't mean we must stay in the past:
 - 3.0 agent (current master branch), will come with a JSON data format and
we already dropped deprecated stuff. We can imagine some structure changes here in
the future (>3.0).
 - I would be gald if we can integrate an optional DMTF CIM output format.

If you want to speed up such inclusion, we need to know if a conversion from 
the agent internal inventory structure is already possible. If it's not the case,
what internal changes are required in the agent.

> Advantage: standards, expandable, interoperability
> Inconvenient: much more work at initial steps
I see we share the same conclusion.

> I'll be back ;-P
Why I'm not suprised? :)

Best regards,
--
           Gonéri