[Fusioninventory-devel] The task/target model issue

Guillaume Rousse Guillaume.Rousse at inria.fr
Mon Oct 11 22:15:39 UTC 2010


Hello list.

Here's the issue I had when reviewing David's SNMPquery module: it uses
a different interpretation of the configuration options passed to the agent.

The current model implemented and documented in the agent is the
following one:
For each given target (through server, local or stdout options),
performs all available tasks independently, and manage each task result
according to the target type (send it to a server, write in in a local
file, or displays it on stdout, respectively).

./agent --server A --server B --local /tmp --stdout

will then run all available tasks 4 times from scratch. With regards to
the standard inventory task, you'll run 4 different inventories.

The behaviour implemented in David task is different:
If my target is something else as a server, abort immediatly. Otherwise,
send my result to the server, and also write it in a local file if a
local target has also been given, even if not the current target.

./agent --server A --server B --local /tmp --stdout

Regarding the snmp inventory task only, it will be executed two times,
each of them being sent to the server AND written locally.

In the first model, --local is a full-class target. In the second model,
--local is a modifier for another target. Even if it is indeed useful
(local SNMP result is nice too), I don't like this semantic difference
very much. We should either find another execution model to accomodate
this need (such as passing target-specific modifiers in a generic way),
or revert to the currently documented model (stric target separation).
-- 
BOFH excuse #284:

Electrons on a bender

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4251 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/fusioninventory-devel/attachments/20101012/e893c6fa/attachment.bin>


More information about the Fusioninventory-devel mailing list