machine-drivers/machine minikube refactor

[spowelljr]

@afbjorklund I remember you talking in the past about essentially forking the machine-drivers/machine and removing all the stuff minikube doesn't use and just maintaining what we use. @x7upLime is interested in this as he was looking into improvements to the Docker provisioner.

Could you provide an outline of the process and any improvements you wanted this to resolve. Trying to centralize this info for others interested in this task.

[afbjorklund]

The process itself would be similar to the creation of the "kvm2" and "qemu2" drivers, that were adopted (from kvm and qemu). Except here we are talking about onboarding the entire libmachine, including any remaining external drivers...

	github.com/Parallels/docker-machine-parallels/v2 v2.0.1
	github.com/docker/machine v0.16.2
	github.com/machine-drivers/docker-machine-driver-vmware v0.1.5

done:

• kvm (external)
• hyperkit (external)
• none/native (included)
• generic/ssh (included)
• qemu (external)

todo:

• errdriver (included)
• virtualbox (included)
• hyperv (included)
• vmware (external)
• parallels (external)

So those that import github.com/docker/machine/libmachine should instead import the minikube libmachine. And then the remaining parts of the old libmachine provisioner should be merged, with the minikube provisioner and drivers ?

Some previous issues, about relocating and extending:

• Move machine and drivers to minikube repositories #9952
• Make the provisioner interface support more container runtimes #10883

Some previous ideas of extending the API has included:

• removing Docker Swarm support, and the cloud drivers
• adding support for container runtimes beyond Docker

The "github.com/docker/machine/commands/mcndirs" is only used by boot2docker/rancheros provisioners.
The "github.com/docker/machine/version" should also be removed, it is only used to check for RC versions...

vendor/github.com/docker/machine
├── commands
│   └── mcndirs
├── drivers
│   ├── errdriver
│   ├── hyperv
│   ├── none
│   └── virtualbox
├── libmachine
│   ├── auth
│   ├── cert
│   ├── check
│   ├── drivers
│   │   ├── plugin
│   │   │   └── localbinary
│   │   └── rpc
│   ├── engine
│   ├── host
│   ├── log
│   ├── mcndockerclient
│   ├── mcnerror
│   ├── mcnflag
│   ├── mcnutils
│   ├── persist
│   ├── provision
│   │   ├── pkgaction
│   │   └── serviceaction
│   ├── shell
│   ├── ssh
│   ├── state
│   ├── swarm
│   ├── version
│   └── versioncmp
└── version

[afbjorklund]

Consider renaming the rpc binaries, from "docker-machine-driver-xxx" to "minikube-machine-driver-xxx"

To show that it is not actually meant to be used with docker-machine, but only with minikube...

docker-machine-driver-kvm2

docker-machine-driver-hyperkit

Keep the separate binaries for linking purposes (shared libraries adding runtime dependencies)

Even though the minikube fork of configuring is currently linking and hardcoding the flags anyway.

docker-machine-driver-parallels

docker-machine-driver-vmware

---

Note: qemu2 is compiled in (like virtualbox), since it doesn't have any library dependencies

It was an external binary for docker-machine, since that was closed for contributions even then

[afbjorklund]

@spowelljr : one thing to consider, is if you want to keep support for the legacy docker tcp socket ?

• Deprecate the old tcp port for docker-env #9229

if you remove the handling of the certificates and only support the ssh socket, it would simplify things...

None of the other container runtimes support tcp:// sockets anyway, they are all using unix:// now.

Some legacy API clients are not supporting the ssh:// from Docker 18.03, and it hardcodes docker. :-(

So the usual workaround is to have the "machine" do the ssh tunneling of the unix socket now instead.

But you could keep it around, for legacy compability - especially on the older Windows platforms

And consider also supporting* the minikube apiserver 8443, in addition to the docker engine 2376 ?

* currently there are some horrible qemu hacks for this, that would not be needed if the driver did it

[afbjorklund]

So this refactoring last year didn't happen, all I managed to do was to merge the qemu driver...

Which was probably a mistake, so should revert that before it gets used in minikube (driver v2)

Apparently some docker-machine users are still using the gitlab fork, maybe have a look at that.

But it is also going EOL (in 2024), so it is "frozen" in the same way as Docker Machine was (2019)

[afbjorklund]

Add external driver repository: https://github.com/minikube-machine/machine-driver-qemu

Note that it contains the docker-machine driver (qemu), and not the minikube driver (qemu2)

I think the other improvements can continue in the "machine" repo, and that this issue is Done.

https://github.com/minikube-machine/machine/issues