- From: Kenneth Kalmer <
>
- To:
- Subject: [chef] A case for 'run once' recipes
- Date: Wed, 23 Sep 2009 16:47:29 +0200
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=EJ21SpaqBaRm1vhNtTWfg+qG5jVRdh3wlIR4svIDRp7PN1USx93gg68z8TKASYw9Kp 8XdObf4nO6tvT98bsPXS0Zxe5XO7yfHIhwMXRlnivD4PeApv8mpPgShL5lr+eHb3TWSu cgpTwwwENHDvtu/vQzxo4OJNLug26PLrThQcc=
Dear Chef's
I've been giving chef a two-day crash course and have to admit to two things: 1) it is insanely powerful, and 2) it lacks what I (and many others) would label as a critical feature: "run once" recipes.
Some background to my claim first. I'm the architect of a wholesale ISP platform [1] here in South Africa. We have a fully automated service provisioning platform in place, built on Rails, ruote [2] and daemon-kit [3]. I was looking at chef specifically to replace parts of the existing shared hosting provisioning processes and leverage the strength of the community behind chef instead of fighting my own battle and duplicating significant efforts.
Joshua Timberman suggested I make my case here and solicit some feedback on the topic from other chefs.
I would love to help chef gain the ability to support 'run once' recipes in client/server mode. When running a recipe the attributes for that specific run are defined, overwriting any attributes present in the recipe be default. Basically what the JSON parameters do with chef-solo.
Spawning new clouds repaidly with chef is only one of its possible use cases, maintaining them is another. Chef would gain a lot of traction and support in the greater ISP arena if these 'run once' features are implemented.
What do you think?
Best
--
Kenneth Kalmer
">
http://opensourcery.co.za
@kennethkalmer
- [chef] A case for 'run once' recipes, Kenneth Kalmer, 09/23/2009
Archive powered by MHonArc 2.6.16.