[dev] [DISCUSS] Introduction of Vagrant driver into libcloud.drivers.compute

[Samuel Marks <sa...@gmail.com>]

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

Re: [dev] [DISCUSS] Introduction of Vagrant driver into libcloud.drivers.compute

[Samuel Marks <sa...@gmail.com>]

*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 <sa...@gmail.com> 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 ;)
>