[chef] Re: Re: RHN, Cobbler and Chef

[Ranjib Dey < >]

although i agree with most of the points , i think the infrastructure backbone will spill over to more than one software/framework. It might be possible for really specific use cases that we can do every thing in chef.

On Thu, Apr 19, 2012 at 12:52 AM, Tim Smith < "> > wrote:

Craig,

Personally I would recommend keeping it all in Chef.  Our company started with a RHN sat server that handled a limited amount of management / deployment on RHEL systems.  We've moved to a pure Chef setup since then and it's made life a lot easier as we can manage all system types in a single location.  It'll probably make your life a lot easier to have it all come from a single location.  Creating two sources of truth will only cause confusion and reduce some of the cool things you can do with Chef via search.

Tim Smith

Operations Engineer

M: +1 707.738.8132

TW: @tas50

webtrends

Real-Time Relevance. Remarkable ROI.™

London | Portland | San Francisco | Melbourne | Tokyo

From: Craig Cook < " target="_blank"> >
Reply-To: " " target="_blank"> " < " target="_blank"> >
Date: Wednesday, April 18, 2012 9:17 AM
To: " " target="_blank"> " < " target="_blank"> >
Subject: [chef] RHN, Cobbler and Chef

I am looking for some provisioning guidance…

 

We have a  Red Hat Satellite server installed, but not well used/configured yet.

 

I’m not sold that RHN is the best solution for us.

 

I want Chef to be the “backbone” app that manages our Red Hat servers, packages, config files, services, etc.

 

Should RHN manage general OS packages and chef do specific things?

 

e.g.  I have a apache role, assign it to a server.  Part of the role says what version of apache to use.  Should that functionality live in cobbler/RHN instead?

 

Should we have a “production” repo that contains all packages and have chef ensure what is locally installed matches the production repo?  Should that be RHN’s job?

 

Is this a “it depends” type answer?

 

Craig