User story #6246
open
Feature idea: Allow other variable types when using the cfengine variable technique
Description
(I probably told everyone by now I'm missing this, but never opened a feature req on it... till now)
Currently the technique only allows using string parameters.
For many cases one would wish to be able to at least define an slist parameter.
Classic example: RPM installs, you might need to give 10 or 20 and lose a lot of visibility if you i.e. add 20 package install steps in NCF.
Using a global .cf file is possible but the automatic "scoping" to a certain group of nodes is then lost, along with the visibility in UI.
Note:
As far as I understood, the ncf method would be able to handle this input and not just strings. I have not tried, but even if it blows up when using an slist, that's not a problem with being able to define the list.
I really think that would be highly desirable.
Updated by François ARMAND about 9 years ago
This is a very, very clear limitation of today parameters.
There is a reason, which that doing reporting on that is hard(er - at least).
Basically, we have two options:
- either say we are waiting for one parameter, and that is not good because we really want to know what package was in error, not a "everything work / nothing worked"
- or have reports for each item. This is a problem at least for client-side generated lists, because well, we don't know what we are expecting on the server.
So we could limit to only server side list, no ? Well, in that case, it leads to inconsistancy in behavior between different kinds of parameters (env variables, data from inventory, etc).
See for ex. #5506 and all its related tickets.
So we are trying (very hard) to find an acceptable generalisation of that :)
Updated by Benoît PECCATTE almost 9 years ago
- Category set to Web - Config management
- Target version set to Ideas (not version specific)
Updated by Alexis Mousset over 5 years ago
The "Variables (any)" technique allows defining strings or dicts variables.