Allow not only [role]_ as prefix for variables but also [collection]_

[widhalmt]

Hi,

We tried to keep the [role]_ naming rule for variables already before it was part of the linter. But, we have some variables that are global to all roles in the collection. Like one role sets up a PKI/CA and others need to know where certificates are placed. Another example is that every role in the collection can be used on its own. But when you want to use them together, you get extra features like more defaults etc. to make interaction easier.

Could you allow [collection]_ prefixes in addition to [role]_ for variable names? Otherwise we would need lot's of extra set_fact tasks we would like to avoid.

We have several collections but the one I'm talking about is our Elastic Stack collection. I opened issue NETWAYS/ansible-collection-elasticstack#159 for internal discussion. But we soon decided that it would be way better to find a solution upstream.

[MarkusTeufelberger]

Kubespray has a pattern where they have a role that does barely anything (I think it used to do nothing at all, task wise) but that contains all their global variables and settings: https://github.com/kubernetes-sigs/kubespray/tree/master/roles/kubespray-defaults. Their other roles then can depend on that one.

Maybe that could be a way to resolve your issue?

Prefixing with the full collection namespace + name + role name would by the way be even better to avoid conflicts, but then it gets a bit out of hand (netways_elasticstack_kibana_foo instead of kibana_foo). Maybe collections should just write everything into their own little dictionary (netways['elasticstack']['kibana']['foo'] instead of kibana_foo)? Would still not make it easier to read/write the reference to those variables though.

[utoddl]

We're in a similar situation where we have a zmaint role inside our mw_cc collection. When included, it expects variables prefixed with mw_cc_zmaint_…, but ansible-lint is complaining about these variables not being prefixed with the role name, even though the included role name is fully qualified.

[tumbl3w33d]

I would like for the prefix to be configurable in general, because a nice_descriptive_rolename plus a_descriptive_variable_name with the current rule forces you to use variables like nice_descriptive_rolename_a_descriptive_variable_name which gets ugly real quick if used in combination with jinja expressions. Lines get long (of course you can wrap, but that improves the situation only so much) and the code itself hard to read.

In general I agree with the point of the rule, however, I'd prefer to configure somewhere in the role metadata something like include_var_prefix, so I could set it to ndr instead of nice_descriptive_rolename or whatever I deem appropriate. This would also make the transition of legacy code much easier, because in fact we prefix all of our vars like that for years already, however, not with the full name but with something more handy.