[chef] Re: Cuken or cucumber-nagios?

[Hedge Hog < >]

On Wed, Aug 29, 2012 at 12:41 AM, Torben Knerr 
<
 >
 wrote:
> Ohai Chefs!
>
> I'm currently struggling with writing cucumber features for my
> recipes, and I'm not sure whether Cuken[1] or cucumber-nagios[2] would
> be the "better" library.

Cuken grew out of cucumber-nagios, and was inspired by Aruba.
Cucken aims to cover more than nagios use cases.
While I have contributed to both, I wouldn't be willing to opine on
which is better.
We currently use cuken.

>
> Can you recommend either of them, or do you have examples of cookbooks
> being tested with them?

Cucken is not aimed at the test/spec or TDD/BDD of individual cookbooks.
To my mind testing/describing specific cookbooks starts to resemble
testing chef[-server/-client/-solo].

Rather, Cuken is intended to help with describing what you have/want
_after_ Chef has done its thing.
This _can_ mean features being run on the machine (local), but
generally, this means features being run against a machine (remote).
This approach also means you will generally spec/test the net result
of more than one cookbook/recipe.
To my mind this makes sense because there is no (practical/real)
concept in chef of having the result of exactly one cookbook - all
chef runs tend to be the net result of having run several cookbooks.

Of course you are not limited to using cuken in this way.
In fact the zenoss example (see the relishapp representation)
illustrates a description of a local development environment, as well
as some VMs.

The proof-of-concept was to see if we could get to the point of
editing one source (the feature files) to describe the dev (or prod)
environment as well as the actual servers.

This seems to work for us. We now:
- build a couple of AMIs from base images (client/server kernel specifics)
- rebundle these AMIs as our base images
- build custom OS specific images from the rebaundled sys-base images
(package/app specifics)
- rebundle these AMIs as our server/client images
- test the Chef configuration results.

All done automatically, with the code described under our features folder.

Note that we use Librarian-Chef and our cookbook recipes are not
currently 'described' using cuken, although we could do this just as
easily as we did with Vangrant's files.
The reason for this is that recipe changes can be rapid and, as
mentioned, the results are rarely atomic.

We may yet expand cuken's scope to our production recipes - which are
more stable.
However, I'm currently of the view that cuken's sweetspot is (yes, I
should update the project description):
 - pre system-convergence (describing the environment of a chef run: dev/prod)
 - post system-convergence (describing the results of a chef run: web
page availability, security tests)

This means we don't spec cookbooks per se.
Rather:
 a) the environment in which cookbooks run and
 b) the results of running those cookboooks.

Hope that helps clarify?
Best wishes

>
> Cheers,
> Torben
>
> [1] https://github.com/hedgehog/cuken
> [2] https://github.com/auxesis/cucumber-nagios



-- 
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
  Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://hedgehogshiatus.com