Project

General

Profile

Actions

User story #6246

closed

Feature idea: Allow other variable types when using the cfengine variable technique

Added by Florian Heigl almost 10 years ago. Updated 7 months ago.

Status:
Rejected
Priority:
N/A
Assignee:
-
Category:
Web - Config management
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:
No

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.


Related issues 3 (1 open2 closed)

Related to Rudder - User story #5506: Customize Nodes by adding attribute on themReleasedFrançois ARMAND2014-11-27Actions
Related to Rudder - User story #1203: Provision options list from external source (URL, JSON, XML...)New2011-04-05Actions
Related to Rudder - User story #6264: Get directive parameter value from external source (kv store, rest, etc)ResolvedActions
Actions #1

Updated by François ARMAND almost 10 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 :)

Actions #2

Updated by Benoît PECCATTE over 9 years ago

  • Category set to Web - Config management
  • Target version set to Ideas (not version specific)
Actions #3

Updated by Alexis Mousset about 6 years ago

The "Variables (any)" technique allows defining strings or dicts variables.

Actions #4

Updated by Alexis Mousset 7 months ago

  • Status changed from New to Rejected
  • Regression set to No

the old technique is deprecated, and we are adding richer types gradually.

Actions

Also available in: Atom PDF