- From: Hedge Hog <
>
- To:
- Subject: [chef] Reusable steps: PoV request
- Date: Tue, 22 Mar 2011 11:03:45 +1100
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=wctFtmKmBXkJb0JZNk4g7Z03e8OFHk9fynXr/FJ7+UwHP443c+FfnHwhepxUkAto9b n0ZE59RVAV8NXDEcxSMMKw5ANQijrbNri1KQ8n4QAUuUigVEW9xAF2K0mFnoN8ano3wJ ZETW8rY5OzoF+I7TKf09MBAymAS1STcJPrKoI=
Hi,
After some patches to split steps out of Cucumber-Nagios, Auxesis
asked me to take the project over.
That should happen in the next while.
Essentially the idea was that the gem Cuken (pronounced cookin') be to
Cucumber-Nagios use cases what Aruba is to Cucumber.
Of course Cuken uses Aruba's steps.
I see that some of Chef's steps were in Cucumber-Nagios - they are now
(refactored in some cases) in Cuken.
In the course of some work I find myself needing some Chef related
steps, which of course exist in Chef in one form or another.
It seems sensible that I copy these into Cuken.
My question: Is there much interest in such a library of reusable
Chef steps, and would Chef (upstream) even consider using such a
library? It would mean a Chef dev dependency on Cuken.
Ideally I'd like to keep things such that you can require just those
steps you need. e.g
require 'cuken/chef/knife'
and
World(::Cuken::Api::Chef::Knife)
Appreciate any thoughts or feedback.
For instance one issue is what is the assumed feature runtime
env/location: The chef server machine, the chef client machine, the
dev machine (or will it be possible to be agnostic about this?)
Best wishes.
P.S.
I also find myself needing some VirtualBox related steps (from the
virtualbox gem), so the scope of Cuken is likely to be dev-sysops use
cases.
--
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com
- [chef] Reusable steps: PoV request, Hedge Hog, 03/21/2011
Archive powered by MHonArc 2.6.16.