Project

General

Profile

Actions

Bug #11963

closed

Please, legitimate "Priority" usage in multi-instance directives

Added by Dmitry Svyatogorov about 6 years ago. Updated about 6 years ago.

Status:
Released
Priority:
N/A
Category:
Documentation
Target version:
Severity:
Minor - inconvenience | misleading | easy workaround
UX impact:
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Priority:
32
Name check:
Fix check:
Regression:

Description

Please note, that https://www.rudder-project.org/doc-4.2/_directives_ordering.html is in fact incomplete.

https://www.mauras.ch/rudder-fun-with-variables.html
is exploiting undocumented fact that "Priority" field takes precedence over alpha-numeric naming order.
It's really useful together with generic_variable_definition, allowing us to make multilevel overriding (like Chef does).

It works because vars in generic_variable_definition are just internal objects, and redeclaration is ok in cfengine.

Example:

bundle common generic_variable_definition
{

  vars:
    "SECURITY_ACCESS_CONF" string => "admins",
            policy => "overridable";

…
    "SECURITY_ACCESS_CONF" string => "admins,etc",
            policy => "overridable";
…

will set generic_variable_definition.SECURITY_ACCESS_CONF = "admins,etc".

Just use another directive with higher "Priority" (0>1>…>10). And last one will be used.

  • M.b. it works with other directives, but (in general) is useless in management of external objects.
    Per contra, it's very useful to override internal declarations, providing scalar priority instead of 2-level name-sorting hell.

It's also a good workaround against single-level group hierarchy.


Subtasks 1 (0 open1 closed)

Architecture #12007: Enforce with a test the behaviour of generic_variable_definitionReleasedNicolas CHARLESActions
Actions

Also available in: Atom PDF