Been using libcloud for a while—even developed wrappers to automate provisioning and deployments—but recently came across the use-case of utilising a local virtual-machine for development; whilst still keeping the same logic to update my local as my test & [sometimes] production deployment pipelines.
So for example the Fabric script running `update_assets` after updating templates in a Django project, can now be shared across my local-development and test servers. Add in some watchdog code [for local] and git hooks [for test-server(s)] and suddenly everything updates continuously. Here's a proof-of-concept: https://github.com/offscale/libcloud/tree/vagrant It wraps the python-vagrant library. Not sure how you want that dependency handled (or if you want me to maintain a fork in the libcloud library). If you like the idea of a libcloud.drivers.compute.vagrant I'll turn this into a proper PR, with test-coverage and all. Interested? :) Samuel Marks http://linkedin.com/in/samuelmarks BTW: Technically vagrant supports AWS, VirtualBox, Hyper-V, docker and host more [via community plugins] https://github.com/mitchellh/vagrant/wiki/Available-Vagrant-Plugins#providers - which would make this a weird PR to libcloud. However one of my [stretch] goals with the offscale packages is to make a base libcloud CLI, FFI layer, and configuration format to replace everyone elses custom jobs (Cloudfoundry's BOSH, Apache jclouds, Hashicorp's Vagrant/Packer [& their other products], &etc.). So a bit of bidirectional support for systems which do similar things wouldn't go amiss ;)
