This also lays the foundation for the possibility of log drivers in the
future, if it is decided that is a direction to pursue.
Signed-off-by: Nathan LeClaire <nathan.leclaire@gmail.com>
Installation of curl is handled directly by libmachine provisioning, so
there is no need to do it and hence wait for SSH to be ready.
Signed-off-by: Vincent Bernat <Vincent.Bernat@exoscale.ch>
Waiting for SSH is done in libmachine. There are some additional steps
after waiting for SSH but none of them seem to require SSH to be ready
to be executed.
Signed-off-by: Vincent Bernat <Vincent.Bernat@exoscale.ch>
VMWare VCloudAir driver is the only one taking an extra step to test
connectivity after machine creation. If this is a desirable step, it
should be done for all drivers in libmachine directly.
Signed-off-by: Vincent Bernat <Vincent.Bernat@exoscale.ch>
OpenStack driver waits for the machine to reach the expected state. This
is already done in libmachine for most instances of this pattern.
Signed-off-by: Vincent Bernat <Vincent.Bernat@exoscale.ch>
Waiting for SSH to start or Docker to be available is a step done
directly in the framework (in libmachine). There is no need for the
driver to do that.
Signed-off-by: Vincent Bernat <Vincent.Bernat@exoscale.ch>
- Update custom ISO to docker 1.6.0.
- Shared folder support for VMware Fusion.
- Updated bats test for Fusion.
Signed-off-by: Fabio Rapposelli <fabio@vmware.com>
The host side ssh NAT port was being chosen by the OS
when the VM was crafted in the `Create` method.
There was no accounting for some other process taking
over the port while the VM is shutoff.
This moves the port provisioning to VM start.
On first start, the OS will supply the port. Subsequent
starts, we see if we can re-use the port, falling back
to delegating the selection to the OS.
Signed-off-by: John Fieber <jrf@ursamaris.org>
Fix for Docker Machine gets stuck on IBM Softlayer #915
The ip address of the provisioned VM was not being stored in the driver IPAddress variable, this variable
was being used to check if the VM ssh service was up. However as the variable was a blank string the actual address being checked defaulted
to localhost:22, as a result the installation steps on the VM only worked if the user was running an ssh daemon on the machine they were using docker-machine from.
Signed-off-by: Rob Smart <smartrob@uk.ibm.com>
Since the refactor done in #756, some methods have been removed from the
driver interface. Remove those methods from `fakedriver`:
- `StartDocker()`
- `StopDocker()`
- `GetDockerConfigDir()`
- `GetSSHCommand()`
Signed-off-by: Vincent Bernat <Vincent.Bernat@exoscale.ch>
