Previously, we hardcoded to using the ruby binary in /opt/vagrant[..].
On some systems, this path is incorrect, so instead we use the
path of the interpreter that is executing the `vagrant lxc sudoers`
command.
I ran into an issue locally where I didnt have lxc installed and some
commands were giving me back some false positives. Weird but this fixes
the problem I was facing.
We're using snapshots in a CI set-up so that a Vagrant cluster can be built
once, then each push to the repository only checked as an incremental
update to the cluster. We copy each LXC VM to a master image, then re-create
the original names as snapshots.
This change corrects a method which assumes the LXC root path in the config
file is a simple directory name, which is only true for directory-backed
instances.
Conflicts:
spec/unit/driver_spec.rb
The LXC provider issues the "fetch_ip" action to look up the IP address
of the container as part of its "ssh_info" action.
Vagrant::LXC::Action.action_fetch_ip checks the machine state using
Builtin::IsState, which calls Vagrant::Machine.state, which also updates
the state in the machine index and acquires a machine index entry lock to do that.
A race condition ensues in WaitForCommunicator.call, where ready_thr tries
to acquire the machine index lock while running ssh_info, and states_thr tries
to acquire the same lock doing its own state look up (env[:machine].state.id).
If they both try to acquire the lock at the same time, one will fail, and
an exception will be raised.
Work around this issue by checking for the desired machine state (:running) in
Vagrant::LXC::Provider.ssh_info, which can get the state from
Vagrant::LXC::Provider.state, which in turn does not write out the state into
the index file and does not acquire the index entry lock.
* for lxc to 1.0.0 using constant Vagrant::LXC::Driver::DEFAULT_CONTAINERS_PATH
* change method Vagrant::LXC::Driver::CLI#version to call lxc-create if lxc-version command not exists (to lxc version 1.0.0)