*bump* FYI: https://github.com/offscale/libcloud/tree/vagrant has been updated a few times
Samuel Marks http://linkedin.com/in/samuelmarks On Sat, Nov 19, 2016 at 3:47 PM, Samuel Marks <[email protected]> wrote: > 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 ;) >
