Output from recent Docker has changed:
Stderr: Error response from daemon: conflict: unable to delete 0ba49dd235e5 (cannot be forced) - image is being used by running container 250bbe980448
Fixes#7245
This commit catches the Errno::EPERM raised by the operating system if
the machine folder is inaccessible and displays it as a more friendly
error message.
This can be an issue on macOS Catalina if virtual machine files are kept
in a special directory (Documents/Downloads/Desktop) that Vagrant's
embedded Ruby is not allowed to access.
Prior to this commit, docker would look for a container ID based on
"Successfully built" string. This output does not exist if a user has
enabled the experimental feature buildkit. This commit updates the build
behavior to match against both kinds of outputs, and instead of using
`scan`, it uses MatchData and groups the container id with match group
name `:id` instead of making hard assumptions with the matches being
contained inside arrays from scan.
At least on macOS combo Catalina + Docker engine 19.03.4 + Docker desktop 2.1.0.4 + vagrant 2.2.6 the original `matches = result.scan(/Successfully built (.+)$/i)` -line fails to generate a match. With this change I can `vagrant up --provider=docker` successfully.
Prior to this commit, the docker action was using the method `prefix` on
an IPv4 and IPv6 address. This works fine for ruby versions 2.5 and
newer, however the ruby shipped with Vagrant is before 2.5, and
therefore the IPv4 and IPv6 classes do not have the prefix method,
resulting in an error. This commit fixes that by using a different
method of determining the prefix.
Prior to this commit, the docker compose build method would not properly
set build_args if given in a Vagrantfile. This commit fixes that by
using the passed in key `extra_args` from the docker build action.
If VirtualBox is installed but the kernel module is missing or the
service is stopped, the usability test should fail without crashing so
we can fall back to other providers.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
In commit 7980178d194bb21bde2e21858fbc969e4cc7eb3f (#10879) I added a
`usable?` class method to `VagrantPlugins::DockerProvider::Provider`.
However, commit 34e53a5a4b208edcc3e25c1f0e3aa0ef56e8d8d9 (#10890)
incorrectly changed it to an instance method. This rendered it
ineffective because it’s called on the class, not an instance. Change
it back to a class method.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Prior to this commit, the docker login action assumed that if there was
a password to authenticate with, Vagrant was using a host vm to run
docker. This is likely due to some legacy decisions with how Vagrant
used to manage running docker. This commit fixes that by only grabbing a
host_vm lock if the host_vm is actually in use, otherwise login
normally.
Prior to this commit, the docker compose driver would _always_ path
expand a host volume no matter what. This is not always the correct
option, for example if that host volume is actually a reference to a key
inside a `volumes` hash instead of a path on disk. This commit changes
that by looking to see if the requested host volume is actually a
defined key inside the compose config, and if not, it will path expand
it like before. Otherwise it will leave the key "as is".
Prior to this commit, if a snapshot restore was run on an entire
environment with some non-existent guests, Vagrant would attempt to list
their snapshots with a nil id. This commit fixes that by returning an
empty list of snapshots if the machine has not been created yet.
