5 ms·

> Showing 122 changed files with 4,156 additions and 2,915 deletions. Wow, that's a lot of code for a tool which is doing little more than creating, starting,

> Showing 122 changed files with 4,156 additions and 2,915 deletions. Wow, that's a lot of code for a tool which is doing little more than creating, starting, stopping, deleting, and zipping-up VMs. Looking at this diff, all I can say is: Holy Java-ish Ruby, Batman! Most of these classes contain two non-helper methods: init and call. That's not a class; that's a function! I'm reminded of this talk, titled "Stop Writing Classes": http://news.ycombinator.com/item?id=3717715 http://news.ycombinator.com/item?id=3717715 I've used Vagrant before, but it always felt like overkill. When I had an issue with it, I cracked open the code and was quickly deterred from digging deeper. I hacked my VM back to working by hand and decided to avoid mucking with Vagrant. The next time I need automated development VM provisioning, I plan to write a very small shell script. Here's an example of getting a box up and running with 7ish commands: http://www.linux-mag.com/id/7673/ http://www.linux-mag.com/id/7673/ For a complete development environment, you only need to additionally mount a shared filesystem and write an entry into your ssh config. All that said, I do think that there is value in having a command line tool which abstracts various machine provisioning APIs. I know that such a thing exists for cloud providers, but I suspect local VMs have some unique concerns. Regardless, it seems like a task that a shell script is best suited for.

bitshift 14y ago
Yes, the project seems to have around 380 files. I'd be interested to hear from the author if he's reading this thread why the codebase is at this size. Perhaps VirtualBox quirks necessitate a large part of it?
- halfasleep 14y ago
  Vagrant does have support for the general case, where something in 7 lines will be a bit more specific. For example, Vagrant will handle cross distro/OS NFS shared folders.
- mitchellh 14y ago
  Vagrant author here. Files in lib/ (core): 71 Files in plugin/: 142 Total: 213. Still a lot of files but not 380, just wanted to point that out. Each individual file is actually rather small. There are only a few larger files in there (Vagrant::Environment actually perhaps being the only one). "Why the codebase is at this size." Well, Vagrant started very small, but in the 3 years of its existence, it has gained a lot of what I've previously heard called as "code wisdom:" * Generic host support since some tasks are host-specific. For example, setting up NFS on Mac OS X differs from Ubuntu which differs from FreeBSD. Vagrant knows this. * Generic guest support. Setting up a variety of things is guest OS specific, so again, Vagrant knows how to configure networks, mount folders, etc. on a variety of different guest operating systems. * VirtualBox bugs. Vagrant has quite a bit of code to work around VirtualBox bugs. * Networking is hard. Vagrant does quite a lot with networking to ensure your networking works as expected. It also does things like port collision detection to verify that any ports you choose won't collide with any other VMs as well as making a best effort to check if that port is open, and erroring in that case as well. * Plugin interface. Almost every part of Vagrant at this point in git master is customizable. This isn't overkill, this was built out of seeing actual human need for this. This lowers the number of features I need in core and actually fights being overkill, because more things can be built with plugins. * Communication abstraction. Linux and POSIX-like guests with SSH is great, but what happens when you want to run Windows guests? SSH CAN work but isn't ideal. For this reason, Vagrant is started to abstract out communication so that Windows can use things like WinRM, completely transparently. Also, if you use something like VMWare, it uses the VMWare guest communication API, which is blazingly faster than SSH. Again, this is all transparent to plugin developers, provisioners, etc. It "just works." It does much more, but I think you get the idea. Building something that "just works" comes at a cost. And that cost is usually complexity. Can you build a very basic tool to control VirtualBox virtual machines in a small shell script? You betcha! Vagrant started this way. Can you make that reusable? Yeah, but prepare to add some complexity. Then make it run on every major OS and support some nifty features and you got yourself a big project. I hope that helps!
Uchikoma 14y ago
See the recent thread on HN, one writes a useful tool, gives it away, top voted comment on HN is a sniping comment about code style.
- vmind 14y ago
  Rather than just an echo chamber of praise? It's good to see multiple points of view and criticism. There's always a place for improvement, and he's right, the codebase doesn't seem particularly ruby-ish.
  - mun2mun 14y ago
    Honestly, does it matter? Do I have to always code in "ruby-ish" while coding in ruby. What should take more preference? Solving a problem or maintaining "ruby-ish", "python-ish" idioms. Besides if the author feels that he can maintain his codebase this way then I don't see any problem in it. I also do not like tone of trashing vagrant just because it's code base is 'shitty'. Vagrant has been godsend for our office synchronizing configurations across multiple machines. It may be easy for some geeks to create a development system using seven command. But there are people who aren't bothered or have less time digging very deep into every documentation on earth. They want to quickly find a base solution for their problem which they can tweak to their need. Vagrant solves problems for those people perfectly.
    - vmind 14y ago
      I don't see any mention of 'shitty', just over-engineering. For the record, I would use Vagrant if I had the need, and probably will in the future (this kind of caveat seems sadly required otherwise I would be painted as somehow opposed to a software project), that said.. Fitting in with the community style/idioms is rather important for a project, especially as it grows in size. When it's a huge codebase, used by many, in many different use-cases, people being able to look into the code to help sort out their own issues is hugely valuable. If someone who knows your programming language and knows your problem domain gets scared off by how your software is architectured/functions, that's not a particularly good sign. But maybe the problem is huge, and all that complexity is needed, and will pay-off now they're looking to have multiple VM providers. But criticism of complexity shouldn't just be tossed aside as 'trashing'.
mkhattab 14y ago
> I've used Vagrant before, but it always felt like overkill. I'm finding Vagrant is an indispensable tool for learning Chef and testing my recipes. Also, having a complete multi-VM setup as a development environment that replicates my production environment has its advantages. So this is good news for me. I very much prefer VMware Fusion to VirtualBox. Can't wait till the next Vagrant release.
- batgaijin 14y ago
  Bit of a non-sequitor, but why are you using Chef instead of Puppet? I don't usually deal with VM stuff, but I've recently started looking into it and it seemed like Puppet had a clear lead in functionality, or perhaps my mind is just playing tricks on me at this time in the morning.
  - bryanwb 14y ago
    I have used both and find that wile Puppet is a good tool, Chef has a clear lead in functionality and in community strength. Also, the Puppet DSL is a pain as u have to learn both it and ruby. I wrote up my thoughts in detail here http://devopsanywhere.blogspot.it/2011/10/puppet-vs-chef-fight.html http://devopsanywhere.blogspot.it/2011/10/puppet-vs-chef-fig...
jacques_chester 14y ago
That you don't like the design and coding style strikes me as a poor reason not to use a system. It's utterly orthogonal to whether that system solves your problem. I am prepared to bet $250 -- your choice of USD or AUD -- that within 1 year your shell script will have grown beyond seven commands.
- adient 14y ago
  I've been using my own bash scripts for a few years to manage local VMs with KVM for dev and I have exactly 6 commands in 249 lines (excluding blank and comments) and never needed more: image, create, start, stop, delete, list. Where can I collect my $250 USD?
  - Despite 14y ago
    Cute, but that wasn't the bet. They were referring to seven bash commands, i.e. "lines". So you lose by 242 commands.
    - adient 14y ago
      A bash command is not a line, and a line is not a "command". But you can be pedantic if you want, I won't stop you. :)
agotterer 14y ago
I've been using Vagrant since the early days. While I have to admit I've spent zero time in the Vagrant source and I'm sure your assessment is accurate, I'm not sure how much I really care that it might be java-ish or bloated or not well written. I like well written code as much as the next guy. But I'm not deploying Vagrant to my production machines to be accessed by millions of users where I need to squeeze a few milliseconds out and I'm not building on top of vagrant as a framework. I use it behind the scenes as a tool to save me time and bootstraps my development servers. And it does that well. You don't need to maintain the internals, which means you can focus on your actual business, which I don't think is writing provisioning tools :) Edited for spelling
picardo 14y ago
The simple interface of Vagrant is intentional. It is built on the Rack spec, which uses middleware that builds on top of each other. There is a talk called "Rack Middleware as General Purpose Abstraction" where John Bender, the lead developer on Vagrant project, explains why he chose to use that interface. You might want to watch it. http://www.youtube.com/watch?v=fcNaiP5tea0 http://www.youtube.com/watch?v=fcNaiP5tea0
mitchellh 14y ago
Vagrant author here. Allow me to address both of your points. First, the "Java-ish" Ruby: I am using the middleware pattern. The classes are used to build up complex sequences of actions[1]. They are reusable and very easily testable. Why classes? Why not modules with functions? It actually started out as modules with functions, but middleware was so _painfully_ the RIGHT way to do things, I can't imagine doing it any other way. Instead of explaining it all, I guide you to this talk I gave on the pattern: http://confreaks.com/videos/961-mwrc2012-rack-middleware-as-a-general-purpose-abstraction http://confreaks.com/videos/961-mwrc2012-rack-middleware-as-... Next, on Vagrant being "overkill." Write a shell script that does the following: Import a virtual machine, setup host only networking, setup shared folders, boots the machine, runs a provisioner within the machine. Wow that is simple. Oh, wait, I need that script to work on Mac, Linux, and Windows. Oh, VirtualBox has some bugs so can you work around that?[2] Also, host only networking requires some guest OS specific setup (Ubuntu different from Fedora different from FreeBSD etc.), so you have to handle that. Right, and it'd be nice if the script didn't setup networking that collided with other machines on the network, so please write in checks that ports and IPs don't collide. Maybe the script should also verify that Guest Additions are properly installed. AND shared folder performance in VirtualBox sucks, so can you modify that script to use NFS? But only on non-Windows, because Windows doesn't support NFS. Did I mention that NFS requires specialized configuration depending on the host OS AND guest OS? So if you're running Mac + Ubuntu its totally different from Linux + FreeBSD. Have fun! Now, make all of that REUSABLE and EXTENSIBLE, while adding in some other features (other types of networking, host name setting, and so on). Yeah, I'd say Vagrant's 3000 line of code count is pretty spot on, and pretty good. [1]: https://github.com/mitchellh/vagrant/blob/391dc392675c73518ebf04252d824fe916e8860b/plugins/providers/virtualbox/action.rb#L124 https://github.com/mitchellh/vagrant/blob/391dc392675c73518e... [2]: https://github.com/mitchellh/vagrant/blob/391dc392675c73518ebf04252d824fe916e8860b/plugins/providers/virtualbox/action/clean_machine_folder.rb https://github.com/mitchellh/vagrant/blob/391dc392675c73518e...
- alexangelini 14y ago
  It is worth searching through all these comments and reading what Mitchell (mitchellh) has to say. It's been very informative getting the author's perspective on every important issue brought up in this thread.
resetexistence 14y ago
The integration with Chef is enough for any engineer using Chef to configure and deploy their software to choose Vagrant over any other solution. The Chef community has had major success in automated testing of their Cookbooks (units of configuration in Chef) and it is all made possible by Vagrant.

bitshift 14y ago

Yes, the project seems to have around 380 files. I'd be interested to hear from the author if he's reading this thread why the codebase is at this size. Perhaps VirtualBox quirks necessitate a large part of it?

halfasleep 14y ago
Vagrant does have support for the general case, where something in 7 lines will be a bit more specific. For example, Vagrant will handle cross distro/OS NFS shared folders.
mitchellh 14y ago
Vagrant author here. Files in lib/ (core): 71 Files in plugin/: 142 Total: 213. Still a lot of files but not 380, just wanted to point that out. Each individual file is actually rather small. There are only a few larger files in there (Vagrant::Environment actually perhaps being the only one). "Why the codebase is at this size." Well, Vagrant started very small, but in the 3 years of its existence, it has gained a lot of what I've previously heard called as "code wisdom:" * Generic host support since some tasks are host-specific. For example, setting up NFS on Mac OS X differs from Ubuntu which differs from FreeBSD. Vagrant knows this. * Generic guest support. Setting up a variety of things is guest OS specific, so again, Vagrant knows how to configure networks, mount folders, etc. on a variety of different guest operating systems. * VirtualBox bugs. Vagrant has quite a bit of code to work around VirtualBox bugs. * Networking is hard. Vagrant does quite a lot with networking to ensure your networking works as expected. It also does things like port collision detection to verify that any ports you choose won't collide with any other VMs as well as making a best effort to check if that port is open, and erroring in that case as well. * Plugin interface. Almost every part of Vagrant at this point in git master is customizable. This isn't overkill, this was built out of seeing actual human need for this. This lowers the number of features I need in core and actually fights being overkill, because more things can be built with plugins. * Communication abstraction. Linux and POSIX-like guests with SSH is great, but what happens when you want to run Windows guests? SSH CAN work but isn't ideal. For this reason, Vagrant is started to abstract out communication so that Windows can use things like WinRM, completely transparently. Also, if you use something like VMWare, it uses the VMWare guest communication API, which is blazingly faster than SSH. Again, this is all transparent to plugin developers, provisioners, etc. It "just works." It does much more, but I think you get the idea. Building something that "just works" comes at a cost. And that cost is usually complexity. Can you build a very basic tool to control VirtualBox virtual machines in a small shell script? You betcha! Vagrant started this way. Can you make that reusable? Yeah, but prepare to add some complexity. Then make it run on every major OS and support some nifty features and you got yourself a big project. I hope that helps!

Uchikoma 14y ago

See the recent thread on HN, one writes a useful tool, gives it away, top voted comment on HN is a sniping comment about code style.

vmind 14y ago
Rather than just an echo chamber of praise? It's good to see multiple points of view and criticism. There's always a place for improvement, and he's right, the codebase doesn't seem particularly ruby-ish.
- mun2mun 14y ago
  Honestly, does it matter? Do I have to always code in "ruby-ish" while coding in ruby. What should take more preference? Solving a problem or maintaining "ruby-ish", "python-ish" idioms. Besides if the author feels that he can maintain his codebase this way then I don't see any problem in it. I also do not like tone of trashing vagrant just because it's code base is 'shitty'. Vagrant has been godsend for our office synchronizing configurations across multiple machines. It may be easy for some geeks to create a development system using seven command. But there are people who aren't bothered or have less time digging very deep into every documentation on earth. They want to quickly find a base solution for their problem which they can tweak to their need. Vagrant solves problems for those people perfectly.
  - vmind 14y ago
    I don't see any mention of 'shitty', just over-engineering. For the record, I would use Vagrant if I had the need, and probably will in the future (this kind of caveat seems sadly required otherwise I would be painted as somehow opposed to a software project), that said.. Fitting in with the community style/idioms is rather important for a project, especially as it grows in size. When it's a huge codebase, used by many, in many different use-cases, people being able to look into the code to help sort out their own issues is hugely valuable. If someone who knows your programming language and knows your problem domain gets scared off by how your software is architectured/functions, that's not a particularly good sign. But maybe the problem is huge, and all that complexity is needed, and will pay-off now they're looking to have multiple VM providers. But criticism of complexity shouldn't just be tossed aside as 'trashing'.

mkhattab 14y ago

> I've used Vagrant before, but it always felt like overkill. I'm finding Vagrant is an indispensable tool for learning Chef and testing my recipes. Also, having a complete multi-VM setup as a development environment that replicates my production environment has its advantages. So this is good news for me. I very much prefer VMware Fusion to VirtualBox. Can't wait till the next Vagrant release.

batgaijin 14y ago
Bit of a non-sequitor, but why are you using Chef instead of Puppet? I don't usually deal with VM stuff, but I've recently started looking into it and it seemed like Puppet had a clear lead in functionality, or perhaps my mind is just playing tricks on me at this time in the morning.
- bryanwb 14y ago
  I have used both and find that wile Puppet is a good tool, Chef has a clear lead in functionality and in community strength. Also, the Puppet DSL is a pain as u have to learn both it and ruby. I wrote up my thoughts in detail here http://devopsanywhere.blogspot.it/2011/10/puppet-vs-chef-fight.html http://devopsanywhere.blogspot.it/2011/10/puppet-vs-chef-fig...

jacques_chester 14y ago

That you don't like the design and coding style strikes me as a poor reason not to use a system. It's utterly orthogonal to whether that system solves your problem. I am prepared to bet $250 -- your choice of USD or AUD -- that within 1 year your shell script will have grown beyond seven commands.

adient 14y ago
I've been using my own bash scripts for a few years to manage local VMs with KVM for dev and I have exactly 6 commands in 249 lines (excluding blank and comments) and never needed more: image, create, start, stop, delete, list. Where can I collect my $250 USD?
- Despite 14y ago
  Cute, but that wasn't the bet. They were referring to seven bash commands, i.e. "lines". So you lose by 242 commands.
  - adient 14y ago
    A bash command is not a line, and a line is not a "command". But you can be pedantic if you want, I won't stop you. :)

agotterer 14y ago

I've been using Vagrant since the early days. While I have to admit I've spent zero time in the Vagrant source and I'm sure your assessment is accurate, I'm not sure how much I really care that it might be java-ish or bloated or not well written. I like well written code as much as the next guy. But I'm not deploying Vagrant to my production machines to be accessed by millions of users where I need to squeeze a few milliseconds out and I'm not building on top of vagrant as a framework. I use it behind the scenes as a tool to save me time and bootstraps my development servers. And it does that well. You don't need to maintain the internals, which means you can focus on your actual business, which I don't think is writing provisioning tools :) Edited for spelling

picardo 14y ago

The simple interface of Vagrant is intentional. It is built on the Rack spec, which uses middleware that builds on top of each other. There is a talk called "Rack Middleware as General Purpose Abstraction" where John Bender, the lead developer on Vagrant project, explains why he chose to use that interface. You might want to watch it. http://www.youtube.com/watch?v=fcNaiP5tea0 http://www.youtube.com/watch?v=fcNaiP5tea0

mitchellh 14y ago

Vagrant author here. Allow me to address both of your points. First, the "Java-ish" Ruby: I am using the middleware pattern. The classes are used to build up complex sequences of actions[1]. They are reusable and very easily testable. Why classes? Why not modules with functions? It actually started out as modules with functions, but middleware was so _painfully_ the RIGHT way to do things, I can't imagine doing it any other way. Instead of explaining it all, I guide you to this talk I gave on the pattern: http://confreaks.com/videos/961-mwrc2012-rack-middleware-as-a-general-purpose-abstraction http://confreaks.com/videos/961-mwrc2012-rack-middleware-as-... Next, on Vagrant being "overkill." Write a shell script that does the following: Import a virtual machine, setup host only networking, setup shared folders, boots the machine, runs a provisioner within the machine. Wow that is simple. Oh, wait, I need that script to work on Mac, Linux, and Windows. Oh, VirtualBox has some bugs so can you work around that?[2] Also, host only networking requires some guest OS specific setup (Ubuntu different from Fedora different from FreeBSD etc.), so you have to handle that. Right, and it'd be nice if the script didn't setup networking that collided with other machines on the network, so please write in checks that ports and IPs don't collide. Maybe the script should also verify that Guest Additions are properly installed. AND shared folder performance in VirtualBox sucks, so can you modify that script to use NFS? But only on non-Windows, because Windows doesn't support NFS. Did I mention that NFS requires specialized configuration depending on the host OS AND guest OS? So if you're running Mac + Ubuntu its totally different from Linux + FreeBSD. Have fun! Now, make all of that REUSABLE and EXTENSIBLE, while adding in some other features (other types of networking, host name setting, and so on). Yeah, I'd say Vagrant's 3000 line of code count is pretty spot on, and pretty good. [1]: https://github.com/mitchellh/vagrant/blob/391dc392675c73518ebf04252d824fe916e8860b/plugins/providers/virtualbox/action.rb#L124 https://github.com/mitchellh/vagrant/blob/391dc392675c73518e... [2]: https://github.com/mitchellh/vagrant/blob/391dc392675c73518ebf04252d824fe916e8860b/plugins/providers/virtualbox/action/clean_machine_folder.rb https://github.com/mitchellh/vagrant/blob/391dc392675c73518e...

alexangelini 14y ago
It is worth searching through all these comments and reading what Mitchell (mitchellh) has to say. It's been very informative getting the author's perspective on every important issue brought up in this thread.

resetexistence 14y ago

The integration with Chef is enough for any engineer using Chef to configure and deploy their software to choose Vagrant over any other solution. The Chef community has had major success in automated testing of their Cookbooks (units of configuration in Chef) and it is all made possible by Vagrant.