I prefer writing small recipes in a yum cookbook that manages the .repo files for yum individually and have yum.conf "include" /etc/yum.repos.d/*.repo files. You can choose to manage your .repo files with a template or with static file resources at that point. Then, bubble up to the role to include/exclude whichever repos your nodes need. You could also have something that deletes extra .repo files from the directory if you care about a clean configuration. I find this much easier to navigate when a sys admin needs to look at the local yum configuration -- they don't need to search through a huge monolithic yum .repo file to find the one they need. For my team, we've also got in-house developed RPMs for our internal services. We manage promotion of the RPMs throughout the SDLC, like so: 1) continuous build artifacts are dropped into a DEV repo, 2) promote to QA those builds that are ready for testing, 3) promote from QA when ready for UAT/production, 4) chef nodes get a different yum repo configuration based on their environment, as defined on the chef server. #1-3 are automated by our orchestration tool, and #4 is a recipe with some logic that ties into node.chef_environment to drop the right yum .repo file in place. On 11/16/12 1:36 PM, "Jamie Winsor" <
">
> wrote:
Bryan,
Our application cookbooks will enable EPEL if they are attempting to retrieve a package which requires it. The same goes for any of our library cookbooks which have a package contained there. We always make these cookbooks configurable, though, so you can instead retrieve your package out of a self hosted repository. EPEL is more of a sensible default for us.
On Friday, November 16, 2012 at 1:29 PM, Bryan McLellan wrote:
|
Archive powered by MHonArc 2.6.16.