Mitchell, firstly, I love you. You're an amazing guy, and you're creating something of great value in the world. I really appreciate you.
OK, so now the constructive criticism: Can you explain the apparent obsession with bringing everything great into vagrant core? I know that core leverages the same plugin architecture that everything else does, but I just can't understand why you privilege "official" plugins above others. Not to mention the fact the it shifts the burden of maintainership onto core developers such as yourself.
(This criticism is coming from someone who in the past has spent a long time working with Drupal, and who has always been disappointed with how that community insists on pulling everything into core, under the guise of "shepherding". As I see it, those pieces then move more slowly and are less likely to see a large maintainer-base who take ownership.)
As for the criticism: spot on, I can see where this would irk you.
I want to first say that the "core" itself is still very slim: you could easily generate a Vagrant installation without a lot of these things. The standard Vagrant distribution, however, is getting more feature packed.
That may be a bit pedantic, so let's talk about the standard Vagrant distribution. It is getting larger, but the primary reason is because I think these features are important enough in the "Vagrant vision" to be available out of the box. Additionally, it shows a bigger promise that I care about the stability of those things.
The "support" issue is one I am very careful about. Luckily Vagrant core has a lot more committers and we have a few "lieutenants" that cover specific areas very well (for example Salt and Ansible provisioners).
As it stands, as the core distribution has grown, I haven't had to spend more time on issues and I still mostly handle the core code. This is largely in part to the fantastic community around Vagrant and the core team that is in place. If I see it shifting otherwise, I'd start to worry.
One more argument for a heavyweight core: Vagrant is perfect for delivering a configured environment to designers and less-experienced developers. But once you start tacking on plugin installation to an already burdensome process (download VirtualBox, download Vagrant, launch Terminal, find the directory, run vagrant up), you lose the 'vagrant up'-and-done quality.
As it stands, your options for plugin installation are:
1) Instruct your users to 'vagrant plugin install XXX' in your README. Hope that they get the right versions.
2) Use "bindler," a now-deprecated plugin manager for Vagrant. That's:'vagrant plugin install bindler', then 'vagrant bindler setup', and finally a 'vagrant plugin install' to auto-install the packages you specify in a JSON file.
Neither very attractive options.
If Vagrant could get support for a plugin manager in core, then I'm all for plugins. I have dreams of 'vagrant up' reading plugin requirements from your Vagrantfile and automatically installing them into that environment only. (@mitchellh? ;) But for now the monolithic core model seems to be working quite well.
--
Anyway, so much fun stuff in this release! Particularly psyched about box versioning and the rsync shared folders—two features I've hackily implemented myself in shell scripts on top of Vagrant 1.3 for work.
One advantage I can see for bringing more providers into the core is the cost of acceptance testing. As a developer of vagrant-libvirt I really hope to add both unit and acceptance tests in order to catch regressions. Some are caused by goofs on our part, and others are caused by changes in newer vagrant versions. Even if we had good acceptance tests, we wouldn't have a CI environment to run them in (we'd need either bare-metal or a VM with nested virtualization). I assume that Hashicorp has invested in such an environment for providers in the Vagrant core that they are commercially supporting.
One problem with using Windows guests on Vagrant is how big they are. You can be looking at 20GB for a stripped down disk with just the OS. This can easily become prohibitive if you want to use more than a few VMs in Vagrant (not to mention the time copying all this redundant data).
Having read about differencing disks, they seem like the perfect solution to this problem, by allowing VMs to share the same parent disk, without needing to copy it (as each VM only needs to keep track of differences to the base disk). From what I've read of differencing disks, this seems like a no-brainer for Vagrant (but unfortunately my experience extends no further than what I've read).
Is there a reason Vagrant doesn't use this approach? Any plans to put this on the roadmap? It seems like this feature is supported by both VirtualBox and Hyper-v.
Differencing disks depend on some things in the core changing. These changes are under way already in branches of Vagrant and Vagrant 1.6 has a very good chance of properly using linked clones wherever possible.
Thanks for the super quick reply! I'm glad to hear I'm not completely crazy with this idea. Multiple 20GB images make my diddy little SSD cry, so this feature would be fantastic.
In the vagrant-libvirt provider (https://github.com/pradels/vagrant-libvirt) we already do this. When you import a box, we load the full QCOW2 disk image into a storage pool. When you create a VM based on that box, we create a new image that is linked to the original image and only stores changes from it. This makes creating new VMs noticeably faster and more space-efficient in libvirt compared to virtualbox. It would be great if other providers used this technique.
Nice work Mitchell! Pretty excited to try this. But...
Is anyone else having problems with this release? On my machine (OSX Mavericks), running any vagrant command is taking ages and is making my computer non responsive. I rebooted, reinstalled vagrant, no luck.
I see in Activity Monitor a ruby process is almost taking over my CPU! at 90%+.
It is probably upgrading your home folder (".vagrant.d") to the new format. That should be IO-bound though, not CPU-bound. Let it run for awhile... I haven't heard of this happening.
Yes, it will be. While we intend for the shares through Vagrant Cloud to be free for personal use, private proxies will cost money when they're available. But we intend for Vagrant Cloud to be fully self-installable and designed it that way!
There are always alternate localhost tunneling solutions you can use if you want a private domain and don't want to pay. But if you want the `vagrant share` integration and a custom domain, we'll be charging for it.
Thanks! We look forward to integrating GitHub – there's a ton of cool stuff that can be done, as it's very common that a box maintainer has Packer templates, configuration management scripts and so forth there.
We didn't go the OAuth route primarily because we need to enable `vagrant login` locally, and for that it's useful to have a login/password combination, authentication tokens. I couldn't think of a workflow that makes this as easy for a user.
I don't mean to this sound snarky, and I really appreciate vagrant. I've had patches merged over the years, so I'm a strong supporter.
BUT, I'd be genuinely interested on the reasoning behind charging for a vmware provider but not the hyperv one? Is it simply that nobody else bothered to develop a vmware provider?
I've considered developing a vmware provider, but don't like the idea of cutting off a vagrant revenue source.
Hi! I'd be happy to say why. VMware itself costs money, unlike VirtualBox which is free. We felt it was fair to charge for a provider where the underlying hypervisor cost money. Additionally, it was our first and only way to support ourselves in developing this product.
If we had a ton of money we'd make the VMware provider free, too. :) But as it is, it is our primary source of income at the moment. Based on interest in on-premise Vagrant Cloud solutions, that may quickly change (hopefully!).
Hyper-V, on the hand, was developed mostly by MS OpenTech. It would be unfair (and likely illegal) to charge for their work they did and contributed as MIT licensed code to Vagrant core.
OK, one criticism for Vagrant Cloud: When creating a box, it provides some default values for name, description etc -- but they are placed into the plaveholder attribute, meaning I still need to enter my own values. I suggest putting them to the value attribute of the form fields, which will speed up things while still allow the users to change the values if they wish.
Me too. We gave up trying to get new hires to reliably create smb shares in the end so have started packaging a smb server with the vm and instead have them mount the shares in windows. It will be nice to rip all of that out and replace it with this.
Hi, Docker maintainer here. I'm not aware of any "bad blood", not everything has to be a war or a competition ;)
Vagrant has been super useful to help us get a VM up and running with Docker pre-installed. But when boot2docker came along with a tiny (25MB!) single-purpose VM, 5 second boot time, way less moving parts and no ruby dependency - it just made sense to use that instead. It also helped reduce the confusion between Vagrant and Docker. We had a lot of people who after installing Docker were confused that now they had to learn this other tool called Vagrant, with a complicated ruby syntax etc. Taking Vagrant out of the equation helped with that too.
I agree. There was definitely no bad blood! I was frustrated with dockers stability at one point and made my feelings public. Perhaps I shouldn't have but I also remember saying at the same time that docker is a fantastic idea :) so... not bad blood. Boot2docker has also been great for the ecosystem so it's all good.
Anyone know why there's no repository for Vagrant? I have to manually download and install the deb|rpm and install it myself, manually, on every new release.
That's what I was thinking.. Found the JS file, Googled for AddTerminalShell to no avail. Didn't know if anyone else could recognize it or if it was custom.
OK, so now the constructive criticism: Can you explain the apparent obsession with bringing everything great into vagrant core? I know that core leverages the same plugin architecture that everything else does, but I just can't understand why you privilege "official" plugins above others. Not to mention the fact the it shifts the burden of maintainership onto core developers such as yourself.
(This criticism is coming from someone who in the past has spent a long time working with Drupal, and who has always been disappointed with how that community insists on pulling everything into core, under the guise of "shepherding". As I see it, those pieces then move more slowly and are less likely to see a large maintainer-base who take ownership.)
<3
EDIT: Holy jeez, Vagrant Cloud is awesome.