Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vagrant core no longer tied to VirtualBox

github.com

Post reply on HN
Print view View original

21–30 of 61 posts

Re: Vagrant core no longer tied to VirtualBox

#21

Post by Uchikoma »

bitshift wrote: post #12

I'm not sure what are the benefits of supporting many VM providers for a tool that is meant for development (as far as I understand at least). Isn't VirtualBox sufficient? It is open source and runs on Linux, OS X and MS Windows. Perhaps I am missing some core idea. Then there is veewee[1] which started life as a Vagrant plugin but as of version 0.3.0 it can be used standalone and one can ssh to the boxes using it, j…

I had so bad experiences with Virtualbox (Dropping interfaces, crashing, ...) and switched to VMWare (Mac OS X). So I applaud the support of different providers.

Re: Vagrant core no longer tied to VirtualBox

#22

Post by rwmj »

vidarh wrote: post #11
rwmj wrote: post #3

Reimplementing libvirt, badly ...

Everytime I try to like libvirt, I start reading the documentation and want to claw my eyes out when I remember just how complicated it makes things. libvirt might be ok if you really need to try to be independent of virtualization technology (though from the looks of it, doing so still requires you to limit yourself to a small subset of functionality) and have really complicated needs, but for a lot of use cases it…

The application development guide is the best place to start: http://libvirt.org/guide/html/index.html

libvirt is (internally) complicated because it really does a huge amount of work for you [the vagrant developers will no doubt discover this over time].

The API isn't so complex, since there are only perhaps 10 calls that you need to know, plus some XML, and it's all documented in extreme detail. If anything I'd say the problem with libvirt is the documentation is too detailed, and there still aren't any good starter API tutorials.

Re: Vagrant core no longer tied to VirtualBox

#23

Post by vmind »

Uchikoma wrote: post #19
snprbob86 wrote: post #9

> 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 Writi…

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.

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.

Re: Vagrant core no longer tied to VirtualBox

#24

Post by mkhattab »

snprbob86 wrote: post #9

> 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 Writi…

> 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.

Re: Vagrant core no longer tied to VirtualBox

#25

Post by vidarh »

rwmj wrote: post #22
vidarh wrote: post #11

Earlier quoted context omitted.

Everytime I try to like libvirt, I start reading the documentation and want to claw my eyes out when I remember just how complicated it makes things. libvirt might be ok if you really need to try to be independent of virtualization technology (though from the looks of it, doing so still requires you to limit yourself to a small subset of functionality) and have really complicated needs, but for a lot of use cases it…

The application development guide is the best place to start: http://libvirt.org/guide/html/index.html libvirt is (internally) complicated because it really does a huge amount of work for you [the vagrant developers will no doubt discover this over time]. The API isn't so complex, since there are only perhaps 10 calls that you need to know, plus some XML, and it's all documented in extreme detail. If anything I'd say…

It's the usage, not the internals, I find overcomplicated.

Every time I've looked at it, I've just ended up writing a small shell script to do what I needed instead rather than having to deal with the convoluted XML config and read through massive amounts of documentation.

Re: Vagrant core no longer tied to VirtualBox

#26

Post by rwmj »

vidarh wrote: post #25
rwmj wrote: post #22

Earlier quoted context omitted.

The application development guide is the best place to start: http://libvirt.org/guide/html/index.html libvirt is (internally) complicated because it really does a huge amount of work for you [the vagrant developers will no doubt discover this over time]. The API isn't so complex, since there are only perhaps 10 calls that you need to know, plus some XML, and it's all documented in extreme detail. If anything I'd say…

It's the usage, not the internals, I find overcomplicated. Every time I've looked at it, I've just ended up writing a small shell script to do what I needed instead rather than having to deal with the convoluted XML config and read through massive amounts of documentation.

If you're writing or editing XML, then you're probably doing it wrong (which to be fair could be a problem with the documentation). You should probably be using commands like:

    virsh start MyGuest
To create guests: virt-install, virt-manager, Boxes, Heat, OpenStack or one of the many other libvirt users. None require XML editing.

In any case, that's not an issue for the topic here. The Vagrant developers will certainly need to read up some libvirt API documentation, but once they have made the sensible decision to use libvirt, then that will be completely hidden inside Vagrant, and wouldn't affect end users of Vagrant in any way.

I added a libvirt backend to libguestfs (previously we were managing KVM processes by hand). The change is completely transparent to libguestfs users.

Re: Vagrant core no longer tied to VirtualBox

#27

Post by mun2mun »

vmind wrote: post #23
Uchikoma wrote: post #19

Earlier quoted context omitted.

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.

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.

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.

Re: Vagrant core no longer tied to VirtualBox

#28

Post by batgaijin »

mkhattab wrote: post #24
snprbob86 wrote: post #9

> 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 Writi…

> 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.

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.

Re: Vagrant core no longer tied to VirtualBox

#29

Post by vidarh »

rwmj wrote: post #26
vidarh wrote: post #25

Earlier quoted context omitted.

It's the usage, not the internals, I find overcomplicated. Every time I've looked at it, I've just ended up writing a small shell script to do what I needed instead rather than having to deal with the convoluted XML config and read through massive amounts of documentation.

If you're writing or editing XML, then you're probably doing it wrong (which to be fair could be a problem with the documentation). You should probably be using commands like: virsh start MyGuest To create guests: virt-install, virt-manager, Boxes, Heat, OpenStack or one of the many other libvirt users. None require XML editing. In any case, that's not an issue for the topic here. The Vagrant developers will certainl…

> To create guests: virt-install, virt-manager, Boxes, Heat, OpenStack or one of the many other libvirt users. None require XML editing.

All of which adds more complexity to do something I can do trivially without libvirt.

I might just not be the right target for it, given that I have the luxury of being able to use only LXC and OpenVz, and in both cases creating and managing VM's with the tools provided is extremely easy.

> In any case, that's not an issue for the topic here. The Vagrant developers will certainly need to read up some libvirt API documentation, but once they have made the sensible decision to use libvirt, then that will be completely hidden inside Vagrant, and wouldn't affect end users of Vagrant in any way.

Of course as someone using mostly LXC and OpenVz, to me Vagrant also seems totally over-engineered for what it does. It's at least a factor of 10 larger than what we use to build and deploy our entire production clusters. I'm very happy I don't have to deal with that kind of complexity just to get some dev environments set up.

Re: Vagrant core no longer tied to VirtualBox

#30

Post by jacques_chester »

snprbob86 wrote: post #9

> 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 Writi…

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.

Post reply on HN