So right now, the existing yumrepo cookbook is a collection of simple
recipes utilizing the yum_repo and yum_key LWRP pieces. I modeled the
default recipe to bootstrap our RHEL/CentOS servers and provide a
baseline of third-party packages early in the run_list. So the whole
cookbook and recipes included are opinionated examples from the fine
folks of the community who have worked on them.
I guess what I am getting at, is maybe the cookbook serves better as
documentation, than a one size fits all re-usable cookbook. Talking
with a few of the end users at the summit, most RHEL/CentOS users seem
to depend on EPEL for something. The latest yum cookbook also has an
EPEL recipe which installs by RPM rather than templating out the .repo
file. Which I think demonstrates most Chef on RHEL users at least need
EPEL for something. The zenoss cookbook also duplicates the
yumrepo::zenoss recipe I have, and it totally makes sense to ship that
code with a cookbook which manages zenoss the service.
The more that I think about shipping the repo management code in a
cookbook that addresses a specific problem space, the more I think that
is probably "the right Chef way". I am open to deprecating the existing
yumrepo, and refactoring that out into individual cookbooks. Simply
keep the deprecated code out there as a functional and documented
example. I'm open to thoughts from real-world and potential users of
the existing cookbook. Yet, one of the problems discussed in length at
the summit is Debian/Ubuntu and RHEL/CentOS world view separation in
Chef cooking. One could make the "case node[:platform]" problem even
worse than what has already been seen in cookbooks.
As far as a "hardware" recipe that covers multi-vendor rack-and-stack
nodes and also "virtual" hardware, I don't think that is the right
approach, at least right now. Those are two different problem spaces.
On the "real hardware" side, our Dell OMSA stuff would make a good fit
in the snmp cookbook. Is that also what the hp-health helper exists to
do, serve up a vendor specific OID tree exposing hardware metrics? On
the other hand, the virtualization tools are hypervisor helper
libraries. Because those tools in the virtualization space have nothing
to do with hardware monitoring or snmp, right?
I am really leaning towards it is better to address a specific problem
space really well, than a multi-faceted cookbook addressing many problem
spaces in a mediocre manner. Once those individual problems are
addressed well, I think it makes sense to bring them all together in a
more generalized cookbook like the "application" or "database" cookbooks.
Existing yumrepo default does this:
- Configures yum.conf by inclusion of yum::yum
- Configures EPEL repo, but installs nothing specific from EPEL.
Duplicate exists in yum::epel
- Configures Dell repos. Installs OpenManage, starts OpenManage, and
optionally downloads hardware specific firmware. Does it belong in a
hardware, dell, or snmp cookbook?
- Configures VMWare repo. Installs vmware-tools helper libraries for
VMs on an ESX hypervisor. Tries to safely remove any manually installed
vmware-tools, in favor of something shipped and managed by yum. So does
that belong in a vmware-tools, or virtualization cookbook? Because this
has really nothing to do with monitoring the VM.
In summary, vmware-tools and Dell OMSA recipes exist. There might be a
misuse of cookbook naming/organization which hide that fact. Like I
said, its an opinionated cookbook. I would love to codify and automate
other people's hardware and virtualization vendor problems. It is hard
for any one person, or only a few, to deliver them all. Anyone who
wants to see more of an "application" or "database" meta-cookbook in
these areas could take on an under-represented problem in that space.
If they don't know how/where to start, I for one, am willing to help.
But one cannot effectively codify a problem they have not seen or
understand. I'm just trying to better understand the problem, and bring
some of the summit ideas and concerns into this discussion.
Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems
Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.696.3428
Email: eric.wolfe@marshall.edu
A programming language is low level when its programs require attention
to the irrelevant.
On 12/01/2011 09:27 AM, Bryan Berry wrote:
Graham, that would be great
On Thu, Dec 1, 2011 at 3:06 PM, Graham Stewart
<graham.stewart@utoronto.ca mailto:graham.stewart@utoronto.ca> wrote:
For the bare metal part, I have a nice simple cookbook we're using
for installing Dell OMSA on a fleet of Dell servers. I'd be happy
to contribute it ...
On 11-12-01 03:04 AM, Bryan Berry wrote:
AtomicPenguin (Eric Wolfe) has put a good bit of work into the
yumrepo
recipes like vmware-tools and dell which detect and installs
virtualization and management tools specific to those hardware or
virtualization platforms.
I would want the similar functionality for a VM running in VMware
Fusion, virtualbox, Xen, etc where adding the
"recipe[hardware]" adds
the paravirtualization tools specific to that platform.
For machine running on actual bare metal, I want
"recipe[hardware]" to
detect and install the hardware management tools, be they
Dell, HP, IBM,
etc.
recipes
default -- detect current hardware or virt platform and
install related
tools
vmware-tools - install the paravirtualization tools for vmware
virtualbox - see vmware-tools
hp - install hp-health tools for bare metal machine
dell - install dell openmanage
ibm - ....
anyone else interested in such a cookbook? I would only do the
subset
that relates to the platforms i use.
By the way, credit for this idea belongs to jpalmer who is
creating
something like this for puppet
--
Graham Stewart graham.stewart@utoronto.ca
<mailto:graham.stewart@utoronto.ca> 416-550-2806 <tel:416-550-2806>
Network and Storage Services Manager, Information Technology Services
University of Toronto Libraries
130 St. George Street
Toronto, Ontario, Canada M5S 1A5
