|
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: 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. 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: "> A programming language is low level when its programs require attention to the irrelevant. On 12/01/2011 09:27 AM, Bryan Berry wrote: " type="cite"> Graham, that would be great |
Archive powered by MHonArc 2.6.16.