rename "none" driver to "native"

[medyagh]

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.

[afbjorklund]

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):

none

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.

generic

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

• docker.github.io/machine/AVAILABLE_DRIVER_PLUGINS.md

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

• https://docs.docker.com/machine/drivers/generic/

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.

machine

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

[tstromberg]

How about native?

[tstromberg]

Other alternatives:

• guest
• raw

I 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.

[medyagh]

I like native

[afbjorklund]

@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"

[fejta-bot]

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

[medyagh]

@sadlil

[sadlil]

/assign

[sadlil]

@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.

[fejta-bot]

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-contributor-experience at kubernetes/community.
/lifecycle stale

[prezha]

@sadlil if you are still working on this, pls let us know, or we might mark this issue as frozen

[sadlil]

@prezha Yes, i will work a little bit more on this. Creating the alias now.

[afbjorklund]

When the driver code is renamed, we can change "driver.BareMetal" (driver.IsNone?) to "driver.IsNative"

The current is a bit confusing, it will return true when running on a VM but false when running in Docker...

// BareMetal returns if this driver is unisolated
func BareMetal(name string) bool {
        return name == None || name == Mock
}

// IsSSH checks if the driver is ssh
func IsSSH(name string) bool {
        return name == SSH
}

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[medyagh]

we are still working on this, there is a WIP PR #10579 by @sadlil

[Ritikaa96]

As the above PR is closed now , is there any other person working on this issue?

[Ritikaa96]

I see that there is an agreement on changing the name and working on this by maintainers here as well. This issue should not get closed.