none is a terrible name.
and doesnt look good at least in integration tests.I suggest we add an alias to none driver.
we could do it in two phases:
change all the current integration tests names to BareMetal
in second phase, if we add an alias, so both none or barmetal be accepted.
none is a terrible name.
No, it is just out of context...
I think this has been described in multiple places, but this is because it was _changed_ from machine:
I'll copy it here (from the "generic" discussion, another legacy driver name used by docker-machine):
And as we discussed earlier, "none" comes for Docker hosts that didn't have _any_ driver.
https://docs.docker.com/machine/get-started-cloud/#add-a-host-without-a-driver
You can register an already existing docker host by passing the daemon url. With that, you can have the same workflow as on a host provisioned by docker-machine.
Basically the name "generic" originates from being the driver for any existing Cloud Provider...
https://docs.docker.com/machine/get-started-cloud/#3rd-party-driver-plugins
So if your cloud didn't have a built-in driver, you could provision your VM and give it to machine.
https://docs.docker.com/machine/get-started-cloud/#drivers-for-cloud-providers
Create machines using an existing VM/Host with SSH.
This is useful if you are using a provider that Machine does not support directly or if you would like to import an existing host to allow Docker Machine to manage.
The terms from docker-machine can be confusing when it comes to minikube...
Since minikube assumes a local docker, and doesn't support any cloud providers.
Now that we have forked the "none" driver, we can rename it like we did with the "kvm2" driver.
But naming things is hard, even if we long considered renaming it as the "libvirt" driver instead.
This is also partly due to #4829
We lack technical documentation...
So, naming.
The problem is that "BareMetal" is also a horrible name. There are two things wrong with it:
The first one is philosophical, and that is that bare metal usually came _before_ the OS itself.
Nowadays it just means non-virtual server, a.k.a. physical server. And more like e.g. Ubuntu.
The second one is that it can be very confusing, when you run the "none" driver on a VM ?
It is then running on "virtual bare metal" (whatever that means). So it still has a hypervisor.
So we could use some other name, perhaps something like "Local" (as opposed to "Remote")
The "none" driver could be the "local" driver, and the "generic" driver could be the "remote" driver.
One just execs things on the localhost, and the other runs commands over ssh to another server.
Another aspect of none is that you probably _should_ be using docker/podman for _some_ isolation.
Basically the current driver is just a fancy kubeadm wrapper, and a never-ending cause for support.
You have people running all kinds of things on the master, and failing to read the documentation...
We added a link to the original documentation now, but the experience is still quite bad outside of CI
(Added in #7649)
See #3760 and #4730
How about native?
Other alternatives:
guestrawI feel like a single-word name may be easier to deal with, particularly for non-native speakers, I'm just not sure what it should be.
I like native
@medyagh : I guess we push this to v1.13.0 ? Would be nice to check compatibility and update documentation properly...
And it would also give me some time to do yet another attempt to implement the remote driver, formerly known as "generic"
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
@sadlil
/assign
@medyagh do we want to rename all of the references of none to native? Or we can just add an alias native for none, so minikube start --driver=native works?
If we do want to rename none, one thing we need to handle carefully is existing clusters using none driver. Even with alias we store the cluster driver its real name, and validates that in next start. We might need to add support so that it doesn't break anything. Anyway I am open to do both, let me know what you prefer.
Most helpful comment
How about
native?