Reusable steps: PoV request

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

Yo,

On 21 March 2011 20:03, Hedge Hog 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 :slight_smile:

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

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

S.

Stephen Nelson-Smith,
Principal Consultant,
Atalanta Systems Ltd,
Web: 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

On Tue, Mar 22, 2011 at 3:59 PM, Stephen Nelson-Smith
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

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 :slight_smile:
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
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

--
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[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

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 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

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 :slight_smile:
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 .
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 :slight_smile:

On Thu, Mar 31, 2011 at 4:38 PM, Patrick Debois 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 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

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 :slight_smile:
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 .
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 :slight_smile:

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
OpenNebula6 and libvirt7 gems e.g use case with EC20
OpenNebula has a libvirt api driver2 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

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, but it could get manual4, 5
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 :slight_smile:

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

On Thu, Mar 31, 2011 at 4:38 PM, Patrick Debois 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 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

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 :slight_smile:
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 .
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 :slight_smile:

Just a point of clarification... I'm not sure that is Stephen's idea,
and in case any one thinks this I'm pretty sure he'd not claim it was

  • people have been chasing this for ages, e.g all the Globus work,
    and even those efforts arose out of earlier efforts to to harness and
    manage disparate machines.

Best wishes.

--
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[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