[keslag]

Vagrant has been a much bigger time sink for me than benefit. The ssh-agent never works while provisioning for nix servers, only during ssh (which I can do using the -- -A regardless). It often gets confused and the machines need to be destroyed and re-created after 1-2 provisioning attempts. Packers (The tool used to create vagrant boxes) lack of support for winrm on windows systems has also been a bone of contention. It requires a number of workarounds (like installing open-ssh) on the windows VM that in no way would be viable on a production windows server. And that divergence allows for the "It works on my machine" bugs which is really the whole point of using Vagrant. I use chef for provisioning, and Vagrant also downloads the chef provisioner every single provision, I suspect it does this with puppet as well, so if you're developing on the go and need to re-provision, you're either out of luck or require an unlimited data plan.

Homebrew Cask also has no oversight for breaking changes, so use this only as a convenience, not a tool to be relied upon. It frequently looses track of applications, and I can't even find where it decides to put some error logs if they're created at all.

Some of these problems could be my lack of experience in operations, but the documentation for these is far from complete. A VM with snapshots and a good backup strategy will serve you better in the short term. This changes if you're attempting to support multiple dev, but if you're a lone guy, then snapshots are far far less buggy.

[falcolas]

Windows is, admittedly, a second class citizen for Vagrant. That said, with one install and one config file change, vagrant is as usable on Windows as it is on the Mac. I keep a number of exploratory Vagrant instances on a USB key (just the files, the boxes default to your "home" directory on the machine), and work on them regularly on both a Mac and Windows.

A quick google search for 'vagrant windows' will lead you to one of many blog posts like this one [1], which point out that your Vagrant experience on Windows will be better if you install Git. This places 'ssh' and 'scp' on your path, and then everything about Vagrant just works, including vagrant ssh. I still prefer to use PuTTY to connect when on Windows, but that's my personal preference.

As for the chef re-provisioning, it is more likely an issue with the environment, not Chef of Vagrant. When Vagrant sees that the Chef binaries are already in place, it will note that and continue with the provisioning. Try it again when you have the git command line tools in your path and see if its still an issue.

However, these problems are with your Windows setup of Vagrant, not Vagrant itself. Vagrant on a Mac requires no such workaround to get the unix tools in place, and casting your aspersions against Vagrant from your experience on Windows when it works out of the box on a Mac is unfair to the tool.

[1] https://eamann.com/tech/vagrant-windows/

[keslag]

I'm talking about running windows inside of Vagrant and having these issues on a Mac. The problems I've detailed have long standing issue logs on github, some closed without resolution. I'm not casting aspersions, I'm explaining my use and my experience. This is valid, regardless of whether you have had the same experience. Regardless, the tool sells itself as working on windows, so it is not only fair, but apt. Providing a counter example is a good rebuttal, but saying my experience is invalid reeks of fanboyism.

[JimDabell]

I haven't experienced any of that, but then I wouldn't use it for Windows in the first place and it doesn't sound like the kind of thing the OP is doing either.

The Salt provisioner doesn't bootstrap Salt every time, so it may be a bug with the Chef provisioner rather than something that's true of all provisioning. Isn't Chef installed by default on most base boxes anyway though? It sounds like you've hit an edge case that you can work around by installing Chef in your base box.

Snapshots and backing up VMs sounds a lot more hassle than Vagrant.

Same goes with Cask – I've never had it lose track of applications. It's hard to see how this could happen, as this mechanic is pretty simple – if it's in the directory, it's present, otherwise it's absent.

[jtreminio]

> I use chef for provisioning, and Vagrant also downloads the chef provisioner every single provision, I suspect it does this with puppet as well, so if you're developing on the go and need to re-provision, you're either out of luck or require an unlimited data plan.

Vagrant won't install Chef or Puppet for you - your provisioning scripts need to do this.

If you're seeing Chef being downloaded every single time you provision, then your scripts are broken and you should fix them, or your 3rd party scripts are broken and you should report a bug.

[keslag]

The chef provisioner which comes as part of vagrant does indeed install chef on the target VM. To say that vagrant is not doing this is splitting hairs.

[jtreminio]

I've never used Chef, with or without Vagrant, but I have used Puppet.

It's generally better to have a shell script install your provisioning tool, or use a box that already has it installed, than depending on Vagrant to do anything for you.

Here's a simple example: https://github.com/puphpet/puphpet/blob/master/archive/puphp...

[geerlingguy]

...or switch to a provisioning tool that doesn't need to be installed on guest VMs (e.g. Ansible), saving a little time every time you provision.

Otherwise, another option is to either use prebuilt Vagrant boxes with your CM tool already installed, or build your own using Packer.

[keslag]

I liked Ansible a lot; during our evaluation I had a single Ansible file provisioning a sample dev setup in around 50 lines. We need to support windows servers primarily, much to my objection, so the 'blessing' of the machine to automate Ansible on windows required a manual step at the time, which wasn't acceptable for our use case. We ended up picking chef, both for it's more agnostic approach to OS's, but also it's much more developer friendly, regardless of it's overly verbose generators, git repository litter, and quirks that still have me scratching my head.

[Quequau]

> Vagrant has been a much bigger time sink for me than benefit.

This has been my experience as well... and I would really, really like to have a system in place where I could painlessly spin up VMs to do development in, so that I could leave my Mac as is.

[mattbrewsbytes]

Build a custom box for Vagrant. I did this and now can spin up a CentOS 7 image with Apache, MySQL (Mariadb), RVM (ruby version manager) and a bunch of utilities (wget, curl, git, etc.) in a matter of minutes. I wrote up a how-to on my blog (in profile). I've tried Puppet but it just seemed like more trouble - that would be useful for 10's or 100's of nodes.

As an example, I wanted to try out Ghost to see if I liked that better than Jekyll/Octopress for a blog, so after 'vagrant init centos7' I had a VM running and I could screw up a ton of stuff then and not care.

[jtreminio]

You might be interested in my FOSS that aims to do just that: https://puphpet.com

[mateuszf]

It's called Docker.

[keslag]

Docker just spins up a VM on OS X with boot2docker so you don't get any real benefit here.

[ithkuil]

Yep, although it creates only one you can run a bunch of containers in it.

It feels almost as a native support, but the hack is betrayed by the networking setup.

I wish it would be possible to just expose ports on the real localhost.

[keslag]

Absolutely, I should have specified 'a single vm' in my response. I didn't understand that when I was first trying to understand boot2docker, and now I'm using imprecise language to help confuse others. Thanks for clarifying.

[Jean-Philipe]

Docker is not a VM and only works on Linux.

[billdstrong]

boot2docker is a commandline interface to docker that works on Windows, Mac and Linux. (Maybe *BSDs too.)

On non Linux systems, it downoads a prebuilt VM, and runs it with Virtualbox.

This is how Docker currently works on other OSes.