We use roles when we can and cookbooks when run-time is necessary.
However we separate our prod chef server from the rest so the role update has to go through a release procedure. This gives us the best of both world with the drawback of having 2 chef servers.
/sigh proofreading will be the end of me. I was going to mention something about the food fight show, but the quote escaped me.On Tue, Jun 11, 2013 at 6:02 PM, Elvin Abordo < " target="_blank"> > wrote:
<zips up flame suit>roles are designed to make the whole system flexible and easy to use.It really depends on your business requirements and current situation. You could be in a situation where you're in a team that is slow to adopt new cultural and workflow changes.Telling a team in that situation "Ok you need to learn just a bit of ruby in order to append the resolv.conf settings. By the way since you're modifying code you need to go through a brand new process before rolling out to production. Oh and remember how you would test in Dev? yea that's not going to work anymore because Dev is now Production" Versus. "Here's a role that's applied to all of our servers, these settings shouldn't ever really change because that's how roles were designed, but since we'd like to add another dns server follow the same format that is in this role"if you're in a team like Riot Games who off the bat know ruby or development processes then hell ya cookbook all the things!While beating the dead horse ..they're there for certain use cases and allowing flexibility. Not everybody is a "devops" ninja. someone on the food fight show said that.To really beat the horse dead. Only the person/team implementing chef needs to use the right ingredients at the right time. You can't take someone else's ideas and or concepts and apply it to your environment expecting Nirvana.With all that said. One needs to take care in using roles. Like cooking there needs to be a balance of everything in my opinion. Roles really need to be used as they were designed [0]"A role is a way to define certain patterns and processes that exist across nodes in a Chef organization as belonging to a single job function."It's safe to say that if a new guy comes into my environment who is new to chef and the culture of devops they can see how my environment looks without having to dig into the chef recipes one by one.--On Tue, Jun 11, 2013 at 5:27 PM, Joshua Miller < " target="_blank"> > wrote:We've moving towards "cookbooks in place of roles". Not being able to version lock roles is a real problem. Note that if you're currently relying on the role-level precedence you may need to rethink.On Tue, Jun 11, 2013 at 12:35 PM, Ranjib Dey < " target="_blank"> > wrote:
i use a combination of both, if i can achieve my customizations just by means of attributes and aggregating recipes, i always prefer to use roles. Its cleaner, by design roles does not allow any logic except attributes and a run list. If i need anything more than this, i use cookbooks/recipes.On Tue, Jun 11, 2013 at 12:31 PM, Larry Wright < " target="_blank"> > wrote:
A few months ago there was some discussion about using cookbooks as containers in place of roles. This started with a blog post that advocated always using cookbooks in place of roles, as I recall (though I can't seem to find it at the moment). Some discussions at work have got me to thinking this might be a useful thing in some cases, so I'm wondering how many of you are actually doing this and what you have found the pros/cons of this approach to be.Thanks in advance--
Larry Wright
Elvin Abordo
Mobile: (845) 475-8744--
Elvin Abordo
Mobile: (845) 475-8744
Archive powered by MHonArc 2.6.16.