- From: Alex Kiernan <
>
- To:
- Subject: [chef] DRYing out yum/recipes/*
- Date: Wed, 9 Oct 2013 14:56:11 +0100
I've been picking over local cookbook changes, one of which aligns to
COOK-3025 (per-repository yum proxy settings).
I then started looking across all the recipes in the yum cookbook and
realised I'd be adding lots of duplication if I started propagating
all the per-repo proxy stuff.
At the moment I've got something that looks like this (taking just the
epel recipe - clearly it wants refactoring differently):
yum_key node['yum']['epel']['key'] do
url node['yum']['epel']['key_url']
action :add
end
yum_repository "epel" do
description "Extra Packages for Enterprise Linux"
url node['yum']['epel']['baseurl']
mirrorlist node['yum']['epel']['url']
action platform?('amazon') ? [:add, :update] : :add
# key node['yum']['epel']['key']
# includepkgs node['yum']['epel']['includepkgs']
# exclude node['yum']['epel']['exclude']
end
current_resource = resources('yum_repository[epel]')
node['yum']['epel'].each do |key, value|
excluded = %w{ baseurl url key_url }
if !excluded.include?(key) && current_resource.respond_to?(key.to_sym)
current_resource.send(key.to_sym, value)
end
end
Does this approach attribute handling make sense? Or should we be
looking to split up the namespace so it's clear what's going to apply
to the underlying provider and what's going to be consumed by the
recipe?
That the attributes which the cookbooks consume are baseurl/url, but
are handed off to the provider as url/mirrorlist seems just plain
confusing to me.
--
Alex Kiernan
- [chef] DRYing out yum/recipes/*, Alex Kiernan, 10/09/2013
Archive powered by MHonArc 2.6.16.