Live data from Hacker News

Vagrant core no longer tied to VirtualBox

github.com

31–40 of 61 posts

Re: Vagrant core no longer tied to VirtualBox

#31
post #27
post #23

Earlier quoted context omitted.

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

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

Re: Vagrant core no longer tied to VirtualBox

#32

This is exciting news. I know one fellow who built a large private cloud for his organisation (about two racks of topline gear) so that they could simulate an architecture of several dozen servers and thousands of complex, concurrent transations. What's it built on? VMWare. He was not totally amused when I sent him a link to Vagrant. (I understand VMWare have similar fleet-orchestration tools, but not development-ori…

LXC is great but does have its limitations. We are currently building a vagrant like solution and GUI for LXC/Vagrant/vSphere/ESXi/Xen/AWS etc which will launch in beta in the next couple of months - sign up at http://10xlabs.net if you are interested in following progress

There seems to be no other way to communicate with you or 10xlabs, so excuse me for cluttering this thread. You have an error on the sign up page - 'lounch' should be 'launch'.

Re: Vagrant core no longer tied to VirtualBox

#33

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

Re: Vagrant core no longer tied to VirtualBox

#34

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

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?

Re: Vagrant core no longer tied to VirtualBox

#35
post #27
post #23

Earlier quoted context omitted.

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

"Besides if the author feels that he can maintain his codebase this way then I don't see any problem in it."

Exactly.

Re: Vagrant core no longer tied to VirtualBox

#36

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

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

Re: Vagrant core no longer tied to VirtualBox

#37
post #23

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.

I was at an academic conference recently where an researcher I respect was talking about paper reviews at a top journal much the same way. His point, if I can attempt to do it justice--was that we sometimes get so caught up in proposing ways to "polish the diamond" that sometimes we forget that it's a diamond we're polishing. Some things are good in their own right, and while yes, they are likely improvable, we as "reviewers" don't usually offer enough recognition of the submission's value, or do it only in a token way in order to excuse the criticism that follows.

The researcher used as an example a recent submission with a novel research method. The other reviewers were caught up in the minutia of the paper, and missed the forrest for the trees: the method itself was more than a worthy enough contribution to the field to be accepted, and they were arguing about significance of the results. Over the course of the next couple of review rounds, this researcher's focus shifted from reviewing the paper to defending it to the other researchers. In the end, after multiple rounds (and likely a couple of years), the vote was 2-1 to reject. At this point the Senior Editor stepped in and published the paper without further revision.

Do we do the same with submissions here?

That conversation was hit me pretty hard, and I hope it will change the way I review.

Re: Vagrant core no longer tied to VirtualBox

#38
post #27

Earlier quoted context omitted.

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

"Besides if the author feels that he can maintain his codebase this way then I don't see any problem in it." Exactly.

If that is the only factor, it might have as well been closed source.

Re: Vagrant core no longer tied to VirtualBox

#39

Earlier quoted context omitted.

"Besides if the author feels that he can maintain his codebase this way then I don't see any problem in it." Exactly.

If that is the only factor, it might have as well been closed source.

That doesn't follow at all. You can still fix bugs in open source programs, even if you disapprove of the coding conventions. It's only equivalent to closed source if you're irrationally attached to a particular style.

Re: Vagrant core no longer tied to VirtualBox

#40

Earlier quoted context omitted.

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

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

Post reply on HN