I prefer to use roles as tags with a run_list, no overriding of attributes
in the role itself.
In our own cookbooks, then, I can add logic to determine attributes based
on roles, e.g.:
# do something for master nodes
# do something for slave nodes
If using community cookbooks, then I put this logic in a wrapper cookbook.
This way, the attributes derived from roles are versioned/tracked, along
I do the same thing with environments.
On Tue, Sep 3, 2013 at 9:54 AM, Elvin Abordo email@example.com wrote:
zips up the flame suit
Someone from opscode has said. “When you get a shiney new hammer,
suddenly, everything becomes a nail” Roles are good and bad. With that
said. You have to know what your infrastructure requires or needs both
present and future. The moment you require logic you need to look at
As an example. I use roles to set values that are static and are unlikely
to change and define various environment specific run lists because that’s
how my company’s business model dictates and provides the most sense to our
day to day operations.