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