Comments in-line.
On 12/02/2011 03:14 AM, Bryan Berry wrote:
"
type="cite">
Great comments as usual Atomic Penguin, I
mean Eric ;)
On Fri, Dec 2, 2011 at 4:43 AM, Eric G.
Wolfe <
">
>
wrote:
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.
Could you elaborate on that problem? Is the problem that
some cookbooks only address EL or deb or is it that
accommodating EL and deb in the same recipe is turning recipe
code into spaghetti?
Yeah, so there is no standardization of service names or package
names across distributions, or even different versions of the same
version for that matter. So if one wants to write a generalized
cookbook to work multiple distributions, one would need to write a
lot of "case" selector code for all the edge cases. Which can
muddle up a recipe with this spaghetti code. Probably the best way
to write simplified generalized recipes, right now, is to
parameterize those selectable pieces out of the recipe and hide them
in the attributes file. That way you still accomplish the selection
of edge cases, and your recipe code remains more readable.
"
type="cite">
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?
True, good point
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:
1. Configures yum.conf by inclusion of yum::yum
2. Configures EPEL repo, but installs nothing specific from
EPEL. Duplicate exists in yum::epel
3. Configures Dell repos. Installs OpenManage, starts
OpenManage, and optionally downloads hardware specific
firmware. Does it belong in a hardware, dell, or snmp
cookbook?
4. 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.
The problem is essentially laziness on my part. I want a
recipe(s) from one cookbook that installs vmware-tools on my
vm whether it is EL or deb. I want the same functionality for
virtualbox. I also need different recipes for vmware-tools
because my vmware-administrator insists on using the tarball
that comes w/ the ESX host.
I think that is probably doable either way you go, tarball install
or package manager install. The manual install process is slightly
different now than previous versions, so you may have to include two
different installation constructs to cover both versions. When I
wrote my own version, our goal was to get vmware-tools
installed/upgraded consistently across hosts. We chose to
standardize on the yum managed version. Therefore I nuked the older
manual installed versions, and installed the version shipped via
yum.
I am taking a guess that your vmware admin doesn't like the
"unmanaged" semantic that ESX reports when using the packages from
VMWare's own repository. All that really means is vmware-tools is
not managed by ESX, the goal here is to manage that component with
Chef. I would like to see the Windows piece be automated for this
space as well, since VMWare has the Windows packages out there in
their public repository.
"
type="cite">
A hardware cookbook seems a good enough place for myself
and others to dump such recipes. I will probably put the the
hw monitoring stuff in there as well. When and if it grows
beyond a few recipes, I will move it into a separate
coookbook.
You point out correctly that hardware monitoring is far
different from paravirtualization tools. I would prefer to
start w/ a broad cookbook and refactor it later than start w/
a small optimized one.
There is this Perl analogy about the camel that it is a horse
designed by committee. It would probably be easier for a single
person to design a duck, otter, and beaver. Once we have those
pieces, it will be easier for the committee to build a better
platypus.
|