Rudder

Florian,

I'm not sure i understand your need..
Would you like to have:
- class with name of group defined ? (node is in group "prod server, so class "prod_server" is defined)
- variables with list of groups of the node ?
- variable with list of nodes that are in the groups ?

Florian,

Could you explain more in details your need on this one ?

I might need a few attempts at getting this right.

First one would be if you want to push down some more logic into a template, not creating a rule for every one of 100s of locations.
If I could say in the template

[%CFEninge r.group_locA:: %]

something

[%CFEninge r.group_locB:: %]

something else

I could skip on putting up 100 variables and 100 rules.
This isn't yet a good example, I guess one might also get there by using a data file pushed to every system.

Accordingly the answer would be:
- class with name of group defined ? (node is in group "prod server, so class "prod_server" is defined)

Yes "Prod Servers" would make a class "prod_servers"
My example would be the following:

Real actual life example

${rudder.param.rudder_file_edit_header}
root
${generic_variable_definition.CRON_ALLOW_ATLASSIAN}
${generic_variable_definition.CRON_ALLOW_PERFORCE}
${generic_variable_definition.CRON_ALLOW_ORACLE}

This would become in a mustache template:

{{vars.rudder.param.rudder_file_edit_header}}
root
{{#classes.atlassian_servers}}
jira
confluence
crowd
{{/#classes.atlassian_servers}}
{{#classes.perforce_servers}}
perforce
{{/#classes.perforce_servers}}
{{#classes.oracle_databases}}
oracle
{{/#classes.oracle_databases}}

Way easier to handle, reduce maintenance, better clarity, less interface interactions when modifying content, and no useless rules rebuilding.

That is doable, we would need a Rudder variable, let's say NODE_GROUPS that would be a list just like MANAGED_NODES_NAME is.

We would then use it in a system technique to define new classes matching these groups.

This as being implemented in #7424, released in 3.2