Vagrant provider

[robparrott]

Consider implementing a provider for Vagrant.

Vagrant, by providing an API around virtualization and provisioning, serves as a simple, local IaaS service. Thus for dev work it makes sense to leverage Vagrant as well thru terraform (particularly for configuration management "DevOps" development work).

A general dev workflow could be:

1. define a server/instance in a terraform setup as a vagrant provided object
2. work on config scripting/puppet/chef/etc. until it works as expected, with source code in a subdir of the terraform working dir
3. modify the tf file to use a remote provider such as AWS of google compute

[astrostl]

I'd love to see this.

[Sharpie]

+1 here as well. In addition to development, this would be an excellent way to play around with terraform.

[knuckolls]

One of the best things about terraform in my opinion is that it parallelizes as much as it can. As far as I'm aware, the default VirtualBox provisioner for Vagrant doesn't support parallel instance creation. The non-free VMWare provisioner does.

Just dropping that in a note here in case it's helpful for anyone who picks up this issue. I'll also throw a +1 in here because Vagrant support would indeed be nice.

[vmadman]

I was a bit surprised to find that Vagrant was not supported when I started playing with Terraform. However, after I thought about it for a bit, it sorta makes sense why. Most of my terraform configs involve DNS entries, auto-scaling groups, security groups, VPCs.. and things like that.

(Obviously my AWS fan-boy is showing, sorry)

So, it would be difficult for Vagrant to simulate those things. Even if the vagrant provider just filled in for the EC2 portion..

• You could not easily include the supplemental items (like ELB) at all, since ELB obviously couldn't load balance your vagrant boxes, and
• Even if your ok with excluding all of that for strictly compute testing, Terraform would need a direct Vagrant adaptation of each and every provider -- subverting to some degree its pluggable architecture by adding additional requirements for plugins.

Still, I'm curious if there would be an elegant way of mitigating those challenges, as Vagrant is a part of my day-to-day workflow (hour-to-hour is likely more precise).

[jimmycuadra]

I'm curious how the implementation of this would work. AFAIK, Vagrant doesn't expose any sort of API that would allow you to treat it as a pseudo cloud platform. Would the Terraform provider for Vagrant just have to generate a Vagrantfile based on the Terraform configuration and shell out to Vagrant to boot things?

[derek-adair]

Cant you just define and build your images in packer? Maybe managing vagrant shares could be interesting though...?

Everything you need to shift from dev > staging > prod is all right at your fingertips right there. Treating Vagrant as a terraform resource seems like it would take Vagrant in a route that it is not meant to go.

[derek-adair]

Are you just trying to manage your developers environments?

[knuckolls]

Using packer to cut a virtualbox or vmdk image, then having a virtualbox or vmware fusion provider to run it with seems like a useful flow.

On Sat, Feb 21, 2015 at 10:17 AM, Derek notifications@github.com wrote:

Are you just trying to manage your developers environments?

— Reply to this email directly or view it on GitHub https://github.com/hashicorp/terraform/issues/265#issuecomment-75378632.

[jimmycuadra]

Vagrant is generally sold as being for development environments, but it has a lot of potential as a platform for testing small server infrastructures. Once a cluster of VMs are running and accessible over a network, there are many tools that can be used against them that don't care whether they're talking to AWS, DigitalOcean, Rackspace, or local Vagrant-backed VMs. It'd be a great way to test Terraform configuration without having to launch real cloud resources that cost money.

[derek-adair]

I believe you can theoretically get terraform to talk with your own hypervisor as a provider if desired, but i'm not sure that's really worth the effort when you can use the free tier at AWS. I've been testing various infrastructures for the past... 2 weeks or so and i've only racked up $3.71 - mind you thats before I realized i could deploy consul on a T2 micro. So if you can't test on 750 hours or so of a micro instance...

Furthermore, there are ways to mimic architecture within a vagrant config managing multiple machines, etc.

Maybe managing atlas vagrant shares via terraform would be neat though?? seems like that would be some kind of middle ground.

[ajlanghorn]

:+1: to this. I'd love to see a Vagrant provider for Terraform.

[phrawzty]

:+1:

[mongrelion]

:+1:

[elchudi]

[wricardo]

:+1:

[nicolai86]

:+1:

[taliesins]

:+1:

[maxenglander]

:+1:

[jessehub]

:metal:

[Morriz]

:+1:

[arozhkov]

+1 for Vagrant support. I'd like to use the same tool on all stages: dev, test, prod. Any cloud provider is fine for last two stages but developers want their local environment.

[AndersDJohnson]

:+1:

[st33v]

:+1:

[denisura]

:+1:

[ilijaljubicic]

:thumbsup:

[meggarr]

+1

[antoniou]

:thumbsup:

[veetow]

huge :+1:

[nordringrayhide]

+1

[elleryq]

+1

[JeanMertz]

I'm surprised that this hasn't happened yet, given that Vagrant and Terraform are both Hashicorp products. :+1:

[peterbourgon]

:+1: please :)

[bhurlow]

:+1:

[AndersDJohnson]

@bhurlow I beat you by 4 months on the ":+1:"... :stuck_out_tongue:

[emdem]

[sahilsk]

Isn't it addition of vagrant provider make vagrant useless? Using terraform i may want to

• launch vagrant instance with provided vbox
• i want to setup networking
• i want provisioning support of chef or shell or etc

Using vagrant i'm already fulfilling above needs. So, if am asking terraform to do them for me, it'll render vagrant useless which is the first baby of Hashicorp. OR if i am asking Terraform to run vagrant up/stop/destroy/etc commands then i'm being lazy.

By not supporting vagrant/VMs Terraform is adhering to its foundation principle: Tool to manage Infrastructure.

[ghost]

+1 me too :)

[shafiqalibhai]

:+1:

[yamaszone]

+1

[wmangano]

👍

[gabriellhrn]

:+1:

[stanchan]

👍

[stephenlauck]

Why is there no vagrant provider for terraform? Seems like a real thing to go from laptop to production using the same provisioning artifacts.

[ghost]

:+1:

[kadamwolfe]

+1

[apparentlymart]

I think a challenge with a Vagrant provider for Terraform is that Terraform generally deals with remote APIs rather than local resources. We could have a provider whose implementation is to shell out to run vagrant up, etc, but that would be pretty unprecedented and would certainly be useful only when running Terraform on a single machine e.g. in a dev environment. There's also a lot of redundancy of functionality between Terraform and Vagrant, with Terraform having its own providers for various systems, and maintaining its own state file that's essentially equivalent to Vagrant's own record-keeping.

I've had success in the past using the Terraform docker provider with a local docker instance as an alternative to Vagrant. It works pretty well because the model translates nicely between the local case and the remote case. We could do something similar with libvirt (e.g. using digitalocean's Go bindings, or various others) to get an interface to all of the VM hypervisors it supports, with the same benefit that libvirt offers both a local and a remote API interface, giving a reasonable story for sharing a configuration between development and deployment, where the difference is just in how the provider is configured.

[cyberious]

While understanding that remote calls vs local calls, I see no reason to not put for effort to allow users to develop and test local than push to provider of choosing. Understanding of course certain provider differences. This would help in providing quick testing for modules and such.

[jBodin86]

Still not available ? Who is the sleeping guy ?

[djoos]

👍

[stack72]

Hi @robparrott,

Thanks so much for the request for the Vagrant provider!

While we'd love to see something like this, we don't currently have any plans to implement this ourselves. Until then, this issue is unlikely to see any movement and remain stale. We're trying to prune the stale issues (that aren't going to be addressed anytime soon) by closing them. Note that we only do this for enhancement requests and not bugs.

We have future plans to enable community plugins to be available easily from the Terraform binary itself, allowing community members to "ship" plugins with Terraform much easier. There isn't a timeline for this yet but we hope that will allow much easier shipping of both new providers and updates to existing.

Thanks!

@stack72