0

Obviously, one of the nicest things about Chef is re-using proven components via cookbooks, especially via the wrapper cookbook approach.

However, how do you choose the cookbook to wrap? Some examples which have wasted a ton of my time.

  • a cookbook that has a configuration erb with hardcoded obsolete, not just deprecated, flags. The service rejects the configuration file. Note: far as I understand, wrapping a corrected template erb is not trivial unless you clone & maintain the whole thing.

  • a cookbook that checks for Ubuntu versions up to 9.0.4, seems to do nothing above that and refers to the obsolete /etc/event.d/ directory.

  • cookbooks have heavy coupling to process supervision tools like runit or bluepill. That's also a cause of headaches if your preferred tool is not on the list and you can't adjust for that.

I have tended to use supermarket.chef.io cookbooks to date, and those mostly worked. Except its cookbook for the service I want seems un-maintained and is up for adoption.

Some ideas:

  • check for recent github commits/last update times. But, what if it just works? Then it shouldn't be updated.

  • stars. but what if the stars were all issued a long time ago, while the cookbook was up-to-date?

  • check for github issues that aren't being closed. Might be better.

  • look at recipes and attributes ahead of time. Works better if you know the target software's setup already however.

  • look at the number of contributors and assess whether its a quick side project or it's likely to stay maintained.

  • running it and looking at the types of errors. The ones I picked above all look to me like cookbooks that are not tracking recent updates on either the OS or the program they are managing but do not have attribute-based flexibility to allow for it.

  • is there a rating site somewhere? Googling that got me food cooking sites

Sorry, I realize that this question is broad in nature. But surely, if re-use is a goal of the Chef ecosystem, then judiciously picking the best community cookbook to wrap is a key ingredient for success for an end user. Aside from any technical skills in using Chef itself.

How do you do it? What are your heuristics?

The large number of me-too cookbooks on github makes me think that this is not a solved problem.

1

Personally, I start by looking at the amount of downloads on supermarket and then looking at the github page directly. If the source isn't in public version control, I move along.

When looking through the code, I really just quickly skim through asking myself the following questions :

a) does this cookbook do one thing only

If it's a cookbook that installs an application, that's all I want it to do. I don't want it to mess around with the rest of the system. ( ex.: touch physical disks, ebs volumes, etc... )

b) if I use this cookbook, will it be extensible

If it's a library cookbook exposing resources, I want those resources to provide an adequate amount of control on whatever subresources it employs. I can't stand a resource that creates a template for a narrow use case, but won't let me modify the template source or template variables adequately.

If it's a recipe based cookbook, then I want most of the relevant bits to be configurable through attributes. I don't altogether mind wrapper cookbooks, but I'll be damn well happier if I can set a few attributes rather than have to much around wrapping other's resources.

| improve this answer | |
  • Sorry, I originally left this question open to grab some more answers if possible. but I kinda forgot about it as I am much more often on stackoverflow than here. Sounds like a reasonable checklist to me. And a a belated thanks for your help. – JL Peyret Feb 24 '16 at 4:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.