Instability stymies team use

[frob]

Issue Type

• Feature Idea
• Documentation Report

Your Environment

Vagrant 1.9.4
VirtualBox 5.1.22r115126
ansible 2.2.1.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides

Your OS

• macOS (10.12.4)

Summary

Every time I need to provision or start a new project I need to go through at least a half hour of failure, troubleshooting, and updating/downgrading to find the correct version of things.

Is there any type of precheck command or composer plugin that we can use to make the task of version finding a bit easier. It seems like even if I stay on the same major version of DrupalVM I get breaking issues from Vagrant/VirtualBox.

[frob]

I honestly don't have much issue making my tools work. My team members don't like using DrupalVM because even though it is working on my machine doesn't mean it will work on their machine.

[geerlingguy]

Is there any type of precheck command or composer plugin that we can use to make the task of version finding a bit easier.

Currently, the presumption is that any versions greater than the minimums defined by Drupal VM (e.g. in default.config.yml) should work. Basically, if you run vagrant up and don't get a fatal error, everything should work.

That said...

It seems like even if I stay on the same major version of DrupalVM I get breaking issues from Vagrant/VirtualBox.

Welcome to my special ring of hell :)

Almost every time I think to myself "oh, Vagrant has finally gotten stable for [Ubuntu 16|Ubuntu 14|CentOS 7|CentOS 6|Debian 8]", a new version comes out that breaks something in one of those environments. Or breaks shared folders on Windows, or breaks networking on Mac OS 10.11, but not 10.12. Etc.

And if it's not Vagrant, than VirtualBox releases an update that breaks networking, or provisioning, or shared folders, or something else :P

It's kind of the nature of virtualization that it will never be perfect.

That said, I maintain a dozen or so Drupal projects that have Drupal VM integrated via Composer, and as long as I've updated the variables that are listed in breaking changes in the CHANGELOG file, they've been working for the past year across my two Macs, a Windows 10 laptop, and my test CI environment (Jenkins on another Mac).

If you can provide more detail on what exactly is breaking, maybe we can find ways to document better workarounds that work in more situations, or find ways to bypass the functionality or software that causes that breaking behavior.

On a related note—Drupal VM now works inside a Docker container (this feature is still only in master, not in a tagged release until I do a little more work on it), so in that sense, you could say it's 100% identical and repeatable in that context—but then again, Docker for Mac runs differently than Docker for Windows... which runs differently than Docker for Linux! And Docker breaks everything every quarter or so as well.

It's just the nature of the complex software we build these days :(

[geerlingguy]

Another thing that I find is most often the case, for developers where a configuration isn't working on that developer's machine, but it works on everyone else's: most often, it's because VirtualBox is a really old release, Vagrant is a really old release, or they're doing things like using a VPN, proxying Internet traffic, have a more exotic customized environment (e.g. running flavor-of-the-month Linux distro with a bleeding-edge filesystem and custom weird encryption settings... that sort of thing).

It's not that all the time, but often enough it seems the users who are the loudest about 'this is stupid, my local custom setup is way better' are the ones who spend a lot of time tinkering with their environments and don't care as much about whether things are reproducible elsewhere :D

[oxyc]

Maybe we should look into adding a version requirement for when VirtualBox is used as well?

It's possible to get the version using (VagrantPlugins::ProviderVirtualBox::Driver::Meta.new).version at least, but I'm guessing there's a better access point somewhere too

[geerlingguy]

@oxyc - Oh, dang... I thought we did enforce a version, but you're right—we don't currently.

I know of at least a dozen cases where someone was on VirtualBox 5.0.x (which doesn't pop an upgrade notice for 5.1.x), and that was causing networking issues.

[frob]

are the ones who spend a lot of time tinkering with their environments and don't care as much about whether things are reproducible elsewhere

Yup, that was we. WAS me. Isn't me any more. Thought I still like to tinker with my local, I keep that crap off of my work lappy. I just want this to work with my Mac running current Mac OS. My expectation is if someone works like this then they need to be able to support their own workflow without affecting the rest of the team/project.

I know of at least a dozen cases where someone was on VirtualBox 5.0.x (which doesn't pop an upgrade notice for 5.1.x), and that was causing networking issues.

Yup, that happened.

Another option is putting a last known test build versions in the README. The versions portion has become out of date. This could be automated as a part of the test build.

Or have another project be a composer plug that can do some better version/prerequisite checking. We could even use json-schema to validate the config.yml. As far as I can tell there is no direct yaml schema parser but we could pass the yaml to json and validate there. This would solve(tm) the problem of breaking config changes.

[frob]

My thoughts on this are, this is a php dev environment tool and composer has become the defacto php project package manager --it wouldn't be unreasonable to put a custom composer plugin as a requirement for use. This is assuming that a composer plugin that is required by a required composer project is available to the root project.

[thom8]

@frob Docker builds would solve much of the stability issues as you can build (provision) once, confirm its all working, then reuse across the team. You can do the same with a VM by pre-provisioning a custom base box.

I ran into similar issues working with a team as the time the VM is built created differences in the environments. Networking issues were the most common but packages and their dependencies were often updated.

This still doesn't solve the issues when updating Vagrant / Vbox tho, but whenever the team runs into issues we always make sure they have the latest version of both unless there a known critical issue and I keep everything on the latest versions to make sure there's no issues.

[frob]

Docker could speed everything up, I still don't think docker is ready on the Mac yet. It probably won't be reliable on Mac for another year. So I don't consider use Docker a good solution. Especially because it still requires the initial build to get ready.

How would I go about pre-provisioning a base box that is used by DrupalVM? How would I do this with vagrant and DrupalVM?

Either way, pre-provisioning is really more of a stopgap solution for teams. Building and managing vm images is exactly the mess that I was in when I started using disposable vagrant development environments. And in all honesty, this is one of the reasons I don't really like the concept of Docker. But I don't want to get into a philosophical discussion here. ;)

[oxyc]

How would I go about pre-provisioning a base box that is used by DrupalVM? How would I do this with vagrant and DrupalVM?

Currently there are no docs for this, but there's an open issue #1126. The concept is #1126 (comment)

[geerlingguy]

See related: #1378

[oxyc]

I looked into it, currently there is now way to detect which provider is being used and therefore we can't add VirtualBox version requirements. :/

References:

• Get current provider in Vagrantfile hashicorp/vagrant#1867
• https://groups.google.com/forum/#!topic/vagrant-up/XIxGdm78s4I

The method we want access to is private https://github.com/mitchellh/vagrant/blob/9c299a2a357fcf87f356bb9d56e18a037a53d138/plugins/commands/provider/command.rb#L40:L45

[oxyc]

Or actually, there is one way but it's dirty and not 100% reliable as it enforces the requirement as long as VBoxManage is available regardless if virtualbox is the provider or not.

Edit: On second thought if we only care whether VirtualBox is installed (not if actually used), we can simply use (VagrantPlugins::ProviderVirtualBox::Driver::Meta.new).version within a rescue block. This can still trigger false positives though...

diff --git a/Vagrantfile b/Vagrantfile
index 9e9a5d2..090d448 100644
--- a/Vagrantfile
+++ b/Vagrantfile
@@ -39,6 +39,7 @@ end
 # Verify version requirements.
 require_ansible_version ">= #{vconfig['drupalvm_ansible_version_min']}"
 Vagrant.require_version ">= #{vconfig['drupalvm_vagrant_version_min']}"
+require_virtualbox_version ">= #{vconfig['drupalvm_virtualbox_version_min']}"
 
 Vagrant.configure('2') do |config|
   # Set the name of the VM. See: http://stackoverflow.com/a/17864388/100134
diff --git a/default.config.yml b/default.config.yml
index 5b7a638..3094a7c 100644
--- a/default.config.yml
+++ b/default.config.yml
@@ -36,6 +36,7 @@ vagrant_cpus: 1
 # Minimum required versions.
 drupalvm_vagrant_version_min: '1.8.6'
 drupalvm_ansible_version_min: '2.2'
+drupalvm_virtualbox_version_min: '5.1.10'
 
 # Force use of ansible_local provisioner, even if Ansible is installed on host.
 force_ansible_local: false
diff --git a/lib/drupalvm/vagrant.rb b/lib/drupalvm/vagrant.rb
index beaa3c4..fa19a8c 100644
--- a/lib/drupalvm/vagrant.rb
+++ b/lib/drupalvm/vagrant.rb
@@ -50,11 +50,19 @@ def ansible_bin
   @ansible_bin ||= which('ansible-playbook')
 end
 
+def vboxmanage_bin
+  @vboxmanage_bin ||= which('VBoxManage')
+end
+
 # Return the ansible version parsed from running the executable path provided.
 def ansible_version
   /^[^\s]+ (.+)$/.match(`#{ansible_bin} --version`) { |match| return match[1] }
 end
 
+def virtualbox_version
+  `#{vboxmanage_bin} --version`
+end
+
 # Require that if installed, the ansible version meets the requirements.
 def require_ansible_version(requirement)
   return unless ansible_bin
@@ -63,6 +71,13 @@ def require_ansible_version(requirement)
   raise_message "You must install an Ansible version #{requirement} to use this version of Drupal VM."
 end
 
+def require_virtualbox_version(requirement)
+  return unless vboxmanage_bin
+  req = Gem::Requirement.new(requirement)
+  return if req.satisfied_by?(Gem::Version.new(virtualbox_version))
+  raise_message "You must install a VirtualBox version #{requirement} to use this version of Drupal VM."
+end
+
 def raise_message(msg)
   raise Vagrant::Errors::VagrantError.new, msg
 end

[geerlingguy]

I think we've had a few fruitful outcomes from this issue, and the most pertinent follow-up for the near term is to put more effort into #1126. #1378 will help with probably 20-30% of the first-time users having trouble with guest additions not being correct, or getting hosts updated correctly. And then #1247 will hopefully help more in the future with inclusion / scaffolding in Drupal projects (more so than Drupal VM already works in that regard, ala BLT).

So, closing this out, and recommending to follow the referenced issues, or open up follow up feature requests with specifics.