# Reusable steps: PoV request **URL:** \ **Category:** Chef Infra (archive)\ **Created:** [March 22, 2011, 12:03am UTC](https://discourse.chef.io/t/reusable-steps-pov-request/1744 "2011-03-22T00:03:45Z")\ **Posts on this page:** 7\ **Page:** 1

**Author:** ![hedgehog](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/hedgehog/32/620_2.png) [@hedgehog](https://discourse.chef.io/u/hedgehog)\ **Post date:** [March 22, 2011, 12:03am UTC](https://discourse.chef.io/t/reusable-steps-pov-request/1744/1 "2011-03-22T00:03:45Z")

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](http://wiki.hedgehogshiatus.com) ---

**Author:** ![AJ\_Christensen](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/aj_christensen/32/525_2.png) [@AJ\_Christensen](https://discourse.chef.io/u/AJ_Christensen)\ **Post date:** [March 22, 2011, 12:27am UTC](https://discourse.chef.io/t/reusable-steps-pov-request/1744/2 "2011-03-22T00:27:01Z")

Yo, On 21 March 2011 20:03, Hedge Hog [hedgehogshiatus@gmail.com](mailto:hedgehogshiatus@gmail.com) wrote: > 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 Library of reusable Chef steps is music to my ears. I was only just discussing this internally and on twitter, today 🙂 > 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?) I've always hoped to have (reusable, Chef-y) features run on the clients, for post-convergence system integration. Regards, AJ > 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](http://wiki.hedgehogshiatus.com) ---

**Author:** ![Stephen\_Nelson\_Smith](https://avatars.discourse-cdn.com/v4/letter/s/eada6e/32.png) [@Stephen\_Nelson\_Smith](https://discourse.chef.io/u/Stephen_Nelson_Smith)\ **Post date:** [March 22, 2011, 4:59am UTC](https://discourse.chef.io/t/reusable-steps-pov-request/1744/3 "2011-03-22T04:59:37Z")

Hello there! > My question: Is there much interest in such a library of reusable > Chef steps Absolutely. This would work very well with the stuff I am doing right now on cucuumber-chef, about which I'll be presenting on Thursday at the cukeup conference in London. I'll post slides afterwards, and a blog summary later on [http://agilesysadmin.net](http://agilesysadmin.net) ## S. Stephen Nelson-Smith, Principal Consultant, Atalanta Systems Ltd, Web: [http://agilesysadmin.net](http://agilesysadmin.net) Twitter: @lordcope Skype: atalanta.systems Telephone: +44 (0) 1223 969819 Mobile: +44 (0) 7917 101919 Atalanta Systems: The Agile Infrastructure Enablers [http://atalanta-systems.com](http://atalanta-systems.com) ---

**Author:** ![hedgehog](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/hedgehog/32/620_2.png) [@hedgehog](https://discourse.chef.io/u/hedgehog)\ **Post date:** [March 31, 2011, 3:47am UTC](https://discourse.chef.io/t/reusable-steps-pov-request/1744/4 "2011-03-31T03:47:31Z")

On Tue, Mar 22, 2011 at 3:59 PM, Stephen Nelson-Smith [stephen@atalanta-systems.com](mailto:stephen@atalanta-systems.com) wrote: > Hello there! > > > My question: Is there much interest in such a library of reusable > > Chef steps > > Absolutely. This would work very well with the stuff I am doing right > now on cucuumber-chef, about which I'll be presenting on Thursday at > the cukeup conference in London. I'll post slides afterwards, and a > blog summary later on [http://agilesysadmin.net](http://agilesysadmin.net) Hi Stephen, Very interesting talk - thank you. FWIW I think the most intriguing element is launching into LXC, only problem is that LXC is more restrictive than VirtualBox, etc, i.e on a Ubuntu host I'm not launching a BSD guest. But aside from those use cases I think LXC launches in Cucumber-Chef will be a great step forward when it comes out. You are right it speeds up by at least one order of magnitude the launch time, and I think number that can be substantially multiplied to get the effect on speeding Dev productivity 🙂 From the audience Q's you'll notice people dread having to rewrite all their Vagrantfiles... I wonder how difficult would it be to launch a LXC by parsing a Vagrantfile... Look forward to seeing your chef steps, hopefully we can eliminate some duplication, and in the process make the result more robust. Best wishes. > ## S. > > Stephen Nelson-Smith, > Principal Consultant, > Atalanta Systems Ltd, > Web: [http://agilesysadmin.net](http://agilesysadmin.net) > Twitter: @lordcope > Skype: atalanta.systems > Telephone: +44 (0) 1223 969819 > Mobile: +44 (0) 7917 101919 > > Atalanta Systems: The Agile Infrastructure Enablers > [http://atalanta-systems.com](http://atalanta-systems.com) -- πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα [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](http://wiki.hedgehogshiatus.com) ---

**Author:** ![Patrick\_Debois](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/patrick_debois/32/440_2.png) [@Patrick\_Debois](https://discourse.chef.io/u/Patrick_Debois)\ **Post date:** [March 31, 2011, 5:38am UTC](https://discourse.chef.io/t/reusable-steps-pov-request/1744/5 "2011-03-31T05:38:58Z")

On 31/03/11 05:47, Hedge Hog wrote: > On Tue, Mar 22, 2011 at 3:59 PM, Stephen Nelson-Smith > [stephen@atalanta-systems.com](mailto:stephen@atalanta-systems.com) wrote: > > > Hello there! > > > > > My question: Is there much interest in such a library of reusable > > > Chef steps > > > > Absolutely. This would work very well with the stuff I am doing right > > now on cucuumber-chef, about which I'll be presenting on Thursday at > > the cukeup conference in London. I'll post slides afterwards, and a > > blog summary later on [http://agilesysadmin.net](http://agilesysadmin.net) > > Hi Stephen, > Very interesting talk - thank you. > FWIW I think the most intriguing element is launching into LXC, only > problem is that LXC is more restrictive than VirtualBox, etc, i.e on a > Ubuntu host I'm not launching a BSD guest. > But aside from those use cases I think LXC launches in Cucumber-Chef > will be a great step forward when it comes out. > You are right it speeds up by at least one order of magnitude the > launch time, and I think number that can be substantially multiplied > to get the effect on speeding Dev productivity 🙂 > From the audience Q's you'll notice people dread having to rewrite all > their Vagrantfiles... > I wonder how difficult would it be to launch a LXC by parsing a Vagrantfile... > Look forward to seeing your chef steps, hopefully we can eliminate > some duplication, and in the process make the result more robust. I've been toying porting the vagrant concept to the cloud with my new laboratory project [GitHub - jedi4ever/mccloud: Vagrant for the cloud](https://github.com/jedi4ever/mccloud) . I'm leveraring the fog library to control different cloud vendors instances up and down. Fog now has experimental support for virtualbox, so instead of being limited to cloud or virtualbox, we could do both. Now if we would write an lxc fog provider, that would fit in nicely with Stephen's idea I think. One tool, many providers for cloud (public/private/personal 🙂 ---

**Author:** ![hedgehog](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/hedgehog/32/620_2.png) [@hedgehog](https://discourse.chef.io/u/hedgehog)\ **Post date:** [March 31, 2011, 7:39am UTC](https://discourse.chef.io/t/reusable-steps-pov-request/1744/6 "2011-03-31T07:39:26Z")

On Thu, Mar 31, 2011 at 4:38 PM, Patrick Debois [Patrick.Debois@jedi.be](mailto:Patrick.Debois@jedi.be) wrote: > On 31/03/11 05:47, Hedge Hog wrote: > > > On Tue, Mar 22, 2011 at 3:59 PM, Stephen Nelson-Smith > > [stephen@atalanta-systems.com](mailto:stephen@atalanta-systems.com) wrote: > > > > > Hello there! > > > > > > > My question: Is there much interest in such a library of reusable > > > > Chef steps > > > > > > Absolutely. This would work very well with the stuff I am doing right > > > now on cucuumber-chef, about which I'll be presenting on Thursday at > > > the cukeup conference in London. I'll post slides afterwards, and a > > > blog summary later on [http://agilesysadmin.net](http://agilesysadmin.net) > > > > Hi Stephen, > > Very interesting talk - thank you. > > FWIW I think the most intriguing element is launching into LXC, only > > problem is that LXC is more restrictive than VirtualBox, etc, i.e on a > > Ubuntu host I'm not launching a BSD guest. > > But aside from those use cases I think LXC launches in Cucumber-Chef > > will be a great step forward when it comes out. > > You are right it speeds up by at least one order of magnitude the > > launch time, and I think number that can be substantially multiplied > > to get the effect on speeding Dev productivity 🙂 > > From the audience Q's you'll notice people dread having to rewrite all > > their Vagrantfiles... > > I wonder how difficult would it be to launch a LXC by parsing a > > Vagrantfile... > > Look forward to seeing your chef steps, hopefully we can eliminate > > some duplication, and in the process make the result more robust. > > I've been toying porting the vagrant concept to the cloud with my new > laboratory project [GitHub - jedi4ever/mccloud: Vagrant for the cloud](https://github.com/jedi4ever/mccloud) . > I'm leveraring the fog library to control different cloud vendors instances > up and down. > Fog now has experimental support for virtualbox, so instead of being limited > to cloud or virtualbox, we could do both. > > Now if we would write an lxc fog provider, that would fit in nicely with > Stephen's idea I think. > One tool, many providers for cloud (public/private/personal 🙂 Apologies in advance if this seems OT, but it does involve some Chef references and use cases.... Interesting, been a while since I hacked on fog... I actually wonder if you aren't better off working with the OpenNebula[6](https://github.com/retr0h/oca) and libvirt[7](https://github.com/mitchellh/libvirt-rb) gems e.g use case with EC2[0](http://www.opennebula.org/documentation:uc3) OpenNebula has a libvirt api driver[2](http://www.opennebula.org/documentation:archives:rel1.4:libvirtapi) in libvirt's main source so the libvirt (libvirt-rb for ruby) library should offer what you need if it is not in oca, e.g. launching LXC. Some OpenNebula oriented Chef recipes are here in case that helps whet the appetite: [https://github.com/cloudscaling/Cloudboot-Recipes](https://github.com/cloudscaling/Cloudboot-Recipes) I suppose I'm wondering if you can't implement a vagrant 'system' for some of these ON-launched-VM's (KVM,EC2,Xen), and launch them using ON's help. But essentially it looks like adding to Vagrant an OpenNebula provisioner or openNebula-solo provisioner(?), akin to the Chef-solo provisioner, i.e. setup opennebula before launching the VM's. Of course the ON provisioner (and libvirtd too?) would need to be setup before the VM's were launched, and given the time it might take, you'd want to be able use any pre-exisitng ON. So it seems one issue is writing something that translates vagrant VM config data to ON's machine definition file, and passes this to ON. So.... it might work like this: ON/libvirt to fire up VM's EC2 | KVM | Xen. Vbox maybe via any code you can see at [3](http://code.google.com/p/vbox-one/), but it could get manual[4](https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/667076), [5](http://stackoverflow.com/questions/2778638/libvirt-and-virtualbox-getting-started) Libvirt to fireup LXC in those VM's All expressed in Vagrant's syntax, and where you have access to 100% Ruby in the Vagrantfile, and 100% Chef for the configuration. Fog may ease some of the pain at some points too 🙂 Of course this might leave Windows users in the cold a little. I mention that only because Mitchell has stated that he can't downgrade Vagrant's JSON gem version because it works on Windows.... so if equivalent functionality on windows is a requirement things might get tough. HTH > -- πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα [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](http://wiki.hedgehogshiatus.com) ---

**Author:** ![hedgehog](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/hedgehog/32/620_2.png) [@hedgehog](https://discourse.chef.io/u/hedgehog)\ **Post date:** [March 31, 2011, 7:45am UTC](https://discourse.chef.io/t/reusable-steps-pov-request/1744/7 "2011-03-31T07:45:37Z")