Hi, im starting with chef, and recently read a comment on a web, by adam jacob.
Talking about the roles and saying that you should only include attributes on
roles when it is absolutly unavoidable.
Then i meet with the “sudo” cookbook saying that you have to use role
attributes.
So, just in order to start off on the right foot.
^^
Alberto Lorenzo.
Role uses by devops for management nodes. So, it is very convenient to use roles for overriding default cookbook attributes for each node as you need.
Role - is very high level abstraction, it helps us to manage nodes. So, with help of attributes in role's descriptions we could easily modify state of our nodes without modifying any cookbook.
--
With best regards, Anton Baranov.
вторник, 3 сентября 2013 г. в 21:21, ocholetrasaleatorias@gmail.com написал:
Hi, im starting with chef, and recently read a comment on a web, by adam jacob.
Talking about the roles and saying that you should only include attributes on
roles when it is absolutly unavoidable.Then i meet with the "sudo" cookbook saying that you have to use role
attributes.So, just in order to start off on the right foot.
^^
Alberto Lorenzo.
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.
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 elvin159@gmail.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
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.
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 cstedman@dyn.com 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
endIf 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.
-CarltonOn Tue, Sep 3, 2013 at 9:54 AM, Elvin Abordo elvin159@gmail.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
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.
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. ocholetrasaleatorias@gmail.com 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 FordAlberto
On Tue, Sep 3, 2013 at 3:46 PM, Carlton Stedman cstedman@dyn.com 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
endIf 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.
-CarltonOn Tue, Sep 3, 2013 at 9:54 AM, Elvin Abordo elvin159@gmail.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
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.