[Fusioninventory-devel] better way to pass parameters to fusioninventory-agent

[Guillaume Rousse]

Le 02/07/2012 22:57, Gonéri Le Bouder a écrit :
> 2012/6/16 Guillaume Rousse <guillomovitch at gmail.com>:
>> Le 13/06/2012 14:47, Gonéri Le Bouder a écrit :
>>
>>> 2012/6/13 Guillaume Rousse <guillomovitch at gmail.com>:
>>>>
>>>> Le 12/06/2012 14:34, Gonéri Le Bouder a écrit :
>>>
>>>
>>> Hi Guillaume,
>>>
>>>> We already had task-specific parameters (such as inventory-only
>>>> parameters), now we
>>>> have task-and-target-specific parameters, which only apply to a specific
>>>> task applied to
>>>> a specific target...
>>>
>>> much like --local /tmp and --stdout today.
>>
>> No. Both of them are standalone target definitions parameters.
> and --html
--html doesn't define a new target, it modifies the behaviour of all 
existing target/task combinations (at least, it is supposed to).

> --local-inventory-fromat=XXX is enough to drop 3 parameters.
Which ones ?

I'm perfectly fine with replacing the binary '--html' option with a 
parametrized '--format' option. I strongly disagree with introducing a 
partial option, that would only apply to a specific task (inventory) 
combined with a specific target type (local).

>> The current set of allowed parameters is
>> - a set of target definitions (--server, --local and --stdout)
>> - any number of other parameters applying to all these targets without
>> distinction
>>
>> You're introducing here a new parameter category: parameters applying to
>> only some of the targets, if previously defined.
> This is already the caase of --html:
>
> $sudo ./fusioninventory-agent --html
> [sudo] password for goneri:
> [error] No target defined, aborting
We apparently don't discuss the same problem here...

>>> This parameters are confusing because there are all about “Inventory”
>>> whereas
>>> the agent can do more.
>>> A suggestion, we can rename them with an "$taskName_" prefix like
>>> inventory_no-category= and load the default value from an INI style
>>> configuration file:
>>
>> Absolutly, and this would be a move toward genericity. However, that's about
>> task-specific parameters, while the current discussion is about
>> target-specific parameters.
> Yes, maybe because so far, it's only possible to use "local" once.
>
>> Until we have a proper execution model, this change is inappropriate.
> What do you have in mind here?
Well, either:
1) drop the ability to run the agent against multiple targets in a 
single run, which will make the problem disapear
2) find a generic way to apply *any* option with *any* specific target

The last point can easily get achieved through some kind of hierarchized 
configuration file format, or custom command-line parsing tool. However, 
this will not be possible with a flat registry key.
-- 
If you only have dollar bills, the vending machine will reject them
		-- Murphy's Laws on Vending Machines n°5