I would not suggest that approach. You want to control that with some kind of node['database']['needs_mordor'] attribute to control it and then in the roles that need mordor you set that attribute to true. If you find yourself duplicating lines all over the place in roles that’s probably an indication that you have a broader type of server which itself needs to be a role that is mixed into all the sub roles.
If you’re worried about setting attributes in role files (since they’re not versioned) you should already be using the role cookbook pattern (and if you’re fighting with follow-on problems, then you probably want to be using policyfiles and move on from roles+environments entirely).
Scenario
to clarify my setup : If i have one particular server that will run 100% of the application stack and all others in the farm use 60% I was looking at how to identify that primary server within a chef run.
I'm currently using the chef wrapper cookbook pattern ...
and in the role assigned to the primary node set as true to override it.
Then to switch this between nodes its simply a case of moving that role to the new server.
That would work for us and obviously i want any solution to fit into native Chef architecture / processes.
Queries :
Would migrating away from environmental wrapper cookbooks to policy files provide any other solutions to this problem?
Should we migrate to policy files anyway as thats a better approach? We'll be implementing Chef Automate with potentially multiple organisations shortly.