Rudder

See #3689 for details:

The rudder variables ${rudder.(.*).(.*)} only work when the complete value of the variable is this rudder variable
It is not possible to do "datacenter-${rudder.param.datacenter1}", which is a bit of a shame
It's true for all variables:

node variable (2.4)
rule variable (2.4)
param variable (2.7)

[...]

Well, I believe there is two completly different topic here:

- parameter and node parametrization (ie: ${rudder.param.XXX} and ${rudder.node.XXXX}) : parametrization binding does not change the cardinality of parametrized variable (ie: if a variable has 3 values with one containing ${rudder.node.id}, then after binding, it still has 3 values, one changed)
- rule parametrization: binding can change (and actually do change, has we are using it almost exclusively to get the list of hostname on which is applied the "hasPolicyServer" rule). That case is hard (what about a variable containing two such parametrization ? How do you specify if you want the full combination space (ie [a,b] & [1,2] => [ [a,1], [a,2], [b,1], [b.2]]), or a sequential walk ([a,1], [b,2]). On which order is the walk is that case ? Etc etc).

So, I think we don't want to expose the second case to user for now, and perhaps we have to think back about how to manage it - I'm not really sur it's "paramtrization" has in "replace that ${} by a value", but more a kind of magic API call that give back a SET of values, and the number of such API call is clearly defined. On the other hand, if we want to expose inventories parameter in ${}, we will have to manage multivalued parametrization.

All in all, implementing the first case will be mostly trivial in 2.7 (not before, because of the refactoring work in deployment service done at that point). The second point need more thinking.

The "second case" above is the one we are talking about in that ticket.