Parallels driver is getting called as a built-in library instead of RPC Server

[legal90]

The issue is well-described in this thread (starting from the linked comment): Parallels/docker-machine-parallels#93 (comment)

We realized that the output of parallels driver does not depend on the actual binary of docker-machine-driver-parallels available in PATH. It appeared that minikube was calling driver's functions as a usual library, without launching the binary as the RPC Server.

I found the root cause of this and will submit a fixing PR very soon

[afbjorklund]

Interesting, this might actually be the same issue as with all other drivers in the registry: #5549

i.e. we see two calls to init, the real one and then a bogus extra call without any information

[tstromberg]

This is definitely not by design -- the docs mention that the driver needs to be downloaded first.

[tstromberg]

@legal90 - if you have a PR to address this, feel free to send the review my way.

[legal90]

@tstromberg I sent a PR which "fixes" this issue by making minikube <-> parallels driver communication trough RPC: #9494

However, based on #9494 (comment), it seems that you guys prefer to have drivers built-in.
If so - I'll send a new PR soon, which will update the docs and remove the check of driver binary.

[afbjorklund]

Some drivers are built-in (like virtualbox), some have an external binary (like docker-machine-driver-kvm2).

Our driver "registry" looks to be rather confused, though. So it might very well be that it tries to do both...

I think the main reason for not building everything in, would be that it would then also link to extra libraries.

For instance, the kvm2 driver requires libvirt to be installed on the host. But virtualbox just uses VBoxManage

[legal90]

@afbjorklund Thank you!
Here is the alternative fix which keeps the parallels driver built-in (as it is since a while) and removes the redundant check of docker-machine-driver-parallels binary: #9517