[chef] Re: Re: Re: Cuken or cucumber-nagios?

[Hedge Hog < >]

On Fri, Aug 31, 2012 at 4:49 PM, Torben Knerr 
<
 >
 wrote:
> Hi,
>
> thanks, that clarifies a lot!
>
> I don't quite get what you mean with environment though (maybe I'm
> confused with Chef environments :-)) but I guess you mean the Chef
> Server and which Recipes it knows, right?

Environment is an overloaded term, 'context' is a better synonym.
We try to avoid single point of failure, so we don't use Chef Server
and rely on chef-solo.
I emphasize that using chef-solo is not possible in all use cases, and
can require you to structure your app in a particular way.

>
> For me there is value in both, testing individual cookbooks as well as
> their composition (roles, node's run_list). For individual cookbooks,
> I'd test on all levels like foodcritic, chefspec,
> minitest-chef-handler and feature tests. For any composition of
> cookbooks I'd be more interested in the net outcome, i.e. cucumber
> features tests against a machine (remote). Don't know if spec tests
> would make sense at that level.
>
> Btw: I was wondering why cucumber features should be run _on_ a
> machine (locally), but it seems to be quite often used in that way

Cuken is not limited to chef/cloud/networked use cases.
It can be the case that you want to verify a single machine has been
setup correctly without network (remote) access.
So far I've run cucumber features locally, after a chef run, when I am
paranoid, e.g. have we really pinned down all versions sufficiently,
or could a system package update still break something.

HTH

> (e.g. test-kitchen does that as well). I always thought of
> cucumber/gherkin as a tool that is especially well suited for
> acceptance-level testing, which IMHO should always be outside-in.
> Would be interested to hear the community's thoughts about that...
>
> Anyways, Cuken vs. cucumber-nagios is now much clearer to me. It's
> interesting to see that current master of cucumber-nagios is now
> re-using the Cuken steps, so with the next gem release you will
> probably get Cuken as well when you use cucumber-nagios :-)
>
> Thanks a lot,
> Torben
>
>
>
>
> On Thu, Aug 30, 2012 at 1:56 AM, Hedge Hog 
> <
 >
>  wrote:
>> 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



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