20 ms·

Vagrant has so many bugs in development (network issues, file syncing issues) that I switched to manually building my own VMs to save time. I would never use it

by joesmo 12y ago

Vagrant has so many bugs in development (network issues, file syncing issues) that I switched to manually building my own VMs to save time. I would never use it or any tech built on top of it in development, let alone production.

malandrew 12y ago
They really need to rewrite it in go. Ruby has been a disaster for this particular project. Don't even get me started on the Nokogiri issues. Everything they've written in go has functioned better IMHO.
- FooBarWidget 12y ago
  Are you using their all in one package or do you install from rubygems? The former should give you no problems. If you are doing the latter... well... you shouldn't.
  - sciurus 12y ago
    Even if you use their all-in-one package, you can still have dependency problems installing vagrant plugins. https://github.com/mitchellh/vagrant/issues/3769 https://github.com/mitchellh/vagrant/issues/3769 https://github.com/mitchellh/vagrant/issues/4278 https://github.com/mitchellh/vagrant/issues/4278
    - FooBarWidget 12y ago
      Yeah but those are plugins, the Vagrant author can't do anything about what third parties do. You mentioned Go as a better language, but Go does not solve that problem it does not support loadable modules at all. If Vagrant were written in Go it wouldn't have supported plugins at all.
  - dandandan 12y ago
    It was much more stable for me when I was installing it through rubygems and managing our middleware's dependencies with bundler directly. We've switched to the embedded ruby and it's a struggle but we deal with it since it's probably MUCH less work to support now that it's standardized across all vagrant installs.
michaelmior 12y ago
Interesting. I haven't experienced any such issues personally.
WestCoastJustin 12y ago
I have been using Vagrant daily, for little over a year and a half, to create fairly complex muli-node lab environments, and have not had similar experiences. The thought of going back to manually doing this again is not a pleasant one! I guess there are a couple places you could look: the OS images you are using (if they are flakey then the entire chain breaks), your machine (SSD makes things go quickly), your vagrant install (try upgrading), your virtualization software (try upgrading), etc. If there are real bugs, then file them on the Vagrant github page [1], and hopefully we can all benefit from the fixes. [1] https://github.com/mitchellh/vagrant/issues https://github.com/mitchellh/vagrant/issues
robinricard 12y ago
For all of the issues I have been facing, most of them were actually triggered by virtualbox. Those issues can be quite annoying but can be solved quite easily if you don't have other VB VMs. Usually, resetting the vbox subnets (I had major issues with those) does the job. On the other side, Vagrant has got some minor issues but let's face it: doing what Vagrant does manually is huge and I prefer composing with those issues than being on my own. When VB works well and don't cause any problem, you can do quite complex setups with Vagrant. I already created a swarm of 5 VMs on my machine to test my deployments locally: Vagrant may not be imperatively useful for developers but I think it's essential for everyone working on deployment and having the devs using it too can greatly improve the life of those deploying the apps. One last point: Vagrant is not made for production and I think Hashicorp has been pretty clear on that. I never tested packer/terraform or consul so I won't say anything on the production-side of what they're doing but I won't judge it until I actually used it. Vagrant may have evolved since the last time you used it, you should give it another chance !
- joesmo 12y ago
  I would consider using it again if I really had to for more than just quickly testing a VM, but to be honest, after wasting days with problems (which the vagrant team is aware of) and then having it fail again and again, I'm not very inclined to. I can see why vagrant encourages a workflow where one destroys the VMs regularly as that would likely avoid a ton of issues at the expense of time wasted. My VMWare machines have been problem free for many months (as well as my manual VBox ones for years) and the only way I'd even consider using it daily again by choice again is to try out their VMWare support ... which is unfortunately paid so I doubt that will happen. On the other hand, using vagrant did point out some severe weaknesses in VirtualBox itself, especially the file syncing support, and made me realize VMWare is worth the money for that alone. I still use vagrant once in awhile if I only need to test a project out for an hour or two. As far as deployment, I could see the potential time savings when dealing with multiple VMs but those would only be realized if they're not offset by a longer time spent dealing with bugs. Still, I may give it another shot in that context when the need arises next.

by joesmo 12y ago

malandrew 12y ago

They really need to rewrite it in go. Ruby has been a disaster for this particular project. Don't even get me started on the Nokogiri issues. Everything they've written in go has functioned better IMHO.

FooBarWidget 12y ago
Are you using their all in one package or do you install from rubygems? The former should give you no problems. If you are doing the latter... well... you shouldn't.
- sciurus 12y ago
  Even if you use their all-in-one package, you can still have dependency problems installing vagrant plugins. https://github.com/mitchellh/vagrant/issues/3769 https://github.com/mitchellh/vagrant/issues/3769 https://github.com/mitchellh/vagrant/issues/4278 https://github.com/mitchellh/vagrant/issues/4278
  - FooBarWidget 12y ago
    Yeah but those are plugins, the Vagrant author can't do anything about what third parties do. You mentioned Go as a better language, but Go does not solve that problem it does not support loadable modules at all. If Vagrant were written in Go it wouldn't have supported plugins at all.
- dandandan 12y ago
  It was much more stable for me when I was installing it through rubygems and managing our middleware's dependencies with bundler directly. We've switched to the embedded ruby and it's a struggle but we deal with it since it's probably MUCH less work to support now that it's standardized across all vagrant installs.

michaelmior 12y ago

Interesting. I haven't experienced any such issues personally.

WestCoastJustin 12y ago

I have been using Vagrant daily, for little over a year and a half, to create fairly complex muli-node lab environments, and have not had similar experiences. The thought of going back to manually doing this again is not a pleasant one! I guess there are a couple places you could look: the OS images you are using (if they are flakey then the entire chain breaks), your machine (SSD makes things go quickly), your vagrant install (try upgrading), your virtualization software (try upgrading), etc. If there are real bugs, then file them on the Vagrant github page [1], and hopefully we can all benefit from the fixes. [1] https://github.com/mitchellh/vagrant/issues https://github.com/mitchellh/vagrant/issues

robinricard 12y ago

For all of the issues I have been facing, most of them were actually triggered by virtualbox. Those issues can be quite annoying but can be solved quite easily if you don't have other VB VMs. Usually, resetting the vbox subnets (I had major issues with those) does the job. On the other side, Vagrant has got some minor issues but let's face it: doing what Vagrant does manually is huge and I prefer composing with those issues than being on my own. When VB works well and don't cause any problem, you can do quite complex setups with Vagrant. I already created a swarm of 5 VMs on my machine to test my deployments locally: Vagrant may not be imperatively useful for developers but I think it's essential for everyone working on deployment and having the devs using it too can greatly improve the life of those deploying the apps. One last point: Vagrant is not made for production and I think Hashicorp has been pretty clear on that. I never tested packer/terraform or consul so I won't say anything on the production-side of what they're doing but I won't judge it until I actually used it. Vagrant may have evolved since the last time you used it, you should give it another chance !

joesmo 12y ago
I would consider using it again if I really had to for more than just quickly testing a VM, but to be honest, after wasting days with problems (which the vagrant team is aware of) and then having it fail again and again, I'm not very inclined to. I can see why vagrant encourages a workflow where one destroys the VMs regularly as that would likely avoid a ton of issues at the expense of time wasted. My VMWare machines have been problem free for many months (as well as my manual VBox ones for years) and the only way I'd even consider using it daily again by choice again is to try out their VMWare support ... which is unfortunately paid so I doubt that will happen. On the other hand, using vagrant did point out some severe weaknesses in VirtualBox itself, especially the file syncing support, and made me realize VMWare is worth the money for that alone. I still use vagrant once in awhile if I only need to test a project out for an hour or two. As far as deployment, I could see the potential time savings when dealing with multiple VMs but those would only be realized if they're not offset by a longer time spent dealing with bugs. Still, I may give it another shot in that context when the need arises next.