Vagrant 1.5 and Vagrant Cloud(vagrantup.com)
vagrantup.com
Vagrant 1.5 and Vagrant Cloud
http://www.vagrantup.com/blog/vagrant-1-5-and-vagrant-cloud.html
50 comments
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.
Hey Pat! HAHA. Thanks for all the compliments.
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.
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.
Still wary, but this is good enough for me. If you're not overburdened, then that's the main thing :) Thanks man
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.
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.
This is really exciting. I'm also glad Vagrant Cloud is in existence, I think that's exactly what they need.
(I also want to see Docker's Index blown out to be a more robust system like that!)
SMB is also huge for Windows users. Even on Linux, I found SMB easier to use and setup than NFS.
(I also want to see Docker's Index blown out to be a more robust system like that!)
SMB is also huge for Windows users. Even on Linux, I found SMB easier to use and setup than NFS.
Thank you sir.
Typo in your blog post: pleasent (should be pleasant). Also: "interetsted" on the "Organization Accounts" page.
Thank you again.
Not quite the awesome criticism sandwich @patcon made, but that's all I can do.
Typo in your blog post: pleasent (should be pleasant). Also: "interetsted" on the "Organization Accounts" page.
Thank you again.
Not quite the awesome criticism sandwich @patcon made, but that's all I can do.
This is hot. Great approach to the same sorts of things we're working on at http://bowery.io and a logical next step for vagrant.
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.
(This page describes differencing disks, and the first diagram under "Using multiple differencing disks with one parent disk" accurately depicts the sort of thing I have in mind here http://technet.microsoft.com/en-us/library/cc720381(v=WS.10)... )
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.
(This page describes differencing disks, and the first diagram under "Using multiple differencing disks with one parent disk" accurately depicts the sort of thing I have in mind here http://technet.microsoft.com/en-us/library/cc720381(v=WS.10)... )
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.
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.
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%+.
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%+.
Alternatives to NFS on Linux...oh god you just made me a happy happy bunny.
Just read the rsync part, I think I love you guys now.
Just read the rsync part, I think I love you guys now.
Second the happy bunny part, surely since it's getting close to Easter.
Guard now just works, yay
Beware of Vagrant 1.5 if you need vagrant-berkshelf. There are serious dependency issues that are not yet solved:
https://github.com/berkshelf/vagrant-berkshelf/issues/141
I had to rollback to 1.4.3
https://github.com/berkshelf/vagrant-berkshelf/issues/141
I had to rollback to 1.4.3
Rsync looks awesome, but having to run the rsync-auto command separately looks like it will be a drag.
There needs to be a plugin that will run rsync-auto automatically on vagrant up/resume, and terminate it on vagrant halt/suspend.
There needs to be a plugin that will run rsync-auto automatically on vagrant up/resume, and terminate it on vagrant halt/suspend.
Is it possible to create a private Vagrant Share "proxy" ?
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.
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.
+1 for a private Vagrant Share - like Hosted Chef versus open source Chef. A few clients I have would pay for this.
Vagrant Share works flawlessly, thank you very much, Mitchell!
This looks awesome. Really excited about Vagrant Cloud. Wish it had the option to sign in with Github but still looking forward to it.
Great work Vagrant Community and HashiCorp Team!
Great work Vagrant Community and HashiCorp Team!
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.
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.
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.
Thanks for your support!
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.
Thanks for your support!
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.
Excited for these new sync options like rsync and smb. I had been using smb shares on my VM in the past to get better performance
mitchell I admire you, for number of commits you make on github.
downloading it now :)
there was some bad blood earlier where you complained about docker stability, they skipped vagrant and build boot2docker.
now vagrant has many features which first came out on docker especially in vagrant cloud.
edit: good to know it is not bad blood, my clarity has improved , curious why the down vote
downloading it now :)
there was some bad blood earlier where you complained about docker stability, they skipped vagrant and build boot2docker.
now vagrant has many features which first came out on docker especially in vagrant cloud.
edit: good to know it is not bad blood, my clarity has improved , curious why the down vote
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.
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.
By the way Mitchell I think we fixed most of your bug reports - thanks and please keep them coming!
I love open source
boot2docker creator here.
boot2docker wasn't made in response to mitchell's remarks. it was made because it could be made, and it was cool.
If you want to learn more about the genesis, see this presentation[1].
[1] https://speakerdeck.com/steeve/boot2docker-at-the-paris-dock...
boot2docker wasn't made in response to mitchell's remarks. it was made because it could be made, and it was cool.
If you want to learn more about the genesis, see this presentation[1].
[1] https://speakerdeck.com/steeve/boot2docker-at-the-paris-dock...
:) good to know
Can't wait to give it a shot, the Vagrant Share feature is really cool.
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.
Is this just a manpower thing?
Is this just a manpower thing?
Does anyone know what terminal emulator they're using for vagrantcloud.com? It looks slick, I just can't identify it.
They're serving up one big JS file: https://d250n10lsq5j8r.cloudfront.net/assets/application-aca...
control-f-ing for 'term' makes it look like it may even just be custom? https://github.com/search?q=var+AddTerminalShell&ref=reposea...
control-f-ing for 'term' makes it look like it may even just be custom? https://github.com/search?q=var+AddTerminalShell&ref=reposea...
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.
Thanks for the help, though!
Thanks for the help, though!
I also really love this terminal emulator and would like to use it myself. Any chance for you to release it?
Vagrant cloud looks awesome. nice and easy share boxes distributions. Good work!
is 1.5 not compatible with 1.4.3 boxes? I had to downgrade because of ruby errors on windows 7.
Its completely compatible, and I run Vagrant 1.5 on Windows! What error did you get? Please report it: https://github.com/mitchellh/vagrant/issues
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.