[chef] Re: Re: Re: Re: Role Attributes yes or not?

[Carlton Stedman < >]

I'm looking for a typo, hehe.

I believe "run_list" is an array of strings, so "include?" sees if it has an element matching; I actually do:
    node.run_list.include?("role[master]")

To check if the node has the role "master" in it's run_list.
-Carlton

On Wed, Sep 4, 2013 at 8:12 AM, aL. < " target="_blank"> > wrote:

Thx for all the replies!

Carlton, can u explain what are you looking when use node.run_list.include?("master") is it a role? a recipe?

Thanks!

--
Si necesitas una máquina para hacer algo y no la compras al final te darás cuenta de que has pagado lo mismo y no tienes la máquina.--Henry Ford

Alberto

On Tue, Sep 3, 2013 at 3:46 PM, Carlton Stedman < " target="_blank"> > wrote:

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.:

  if node.run_list.include?("master")

    # do something for master nodes

  else 

    # do something for slave nodes

  end

If using community cookbooks, then I put this logic in a wrapper cookbook.

This way, the attributes derived from roles are versioned/tracked, along with cookbooks.

I do the same thing with environments.
-Carlton

On Tue, Sep 3, 2013 at 9:54 AM, Elvin Abordo < " target="_blank"> > 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 wrapper cookbooks. 

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.