Minikube: Stop supporting the vmwarefusion driver

Created on 12 Oct 2017 · 13Comments · Source: kubernetes/minikube

We don't currently run any integration tests on the vmwarefusion driver. There are no devs currently working on supporting this driver, so we should stop supporting it.

cvmwarefusion lifecyclrotten

Source

r2d4

👍2

Most helpful comment

@r2d4 Please, don't! It is superior to VirtualBox in terms of performance and it cost is less than a (Starbucks) coffee per month! Well, when you release docker-machine-driver-hyperkit, then it would be a different story and you can even drop VirtualBox support on macOS and nobody will even notice!

nikolay on 16 Oct 2017

👍7

All 13 comments

nikolay on 16 Oct 2017

👍7

agree @nikolay. If you guys accept #2118, then it's a different story. I (and/or someone in our team) can help support this driver. but please don't throw it away!

anfernee on 3 Nov 2017

👍2

We have the same issue at minishift, and we will be dropping support of VMware too.

gbraad on 5 Nov 2017

Seconding @anfernee , we're on the same team and I can also help support the driver.

dougm on 7 Nov 2017

A good place to start would be to look through open issues tagged with vmwarefusion as the driver and try to tackle some of them:
https://github.com/kubernetes/minikube/issues?q=is%3Aissue+is%3Aopen+label%3Adriver%2Fvmwarefusion

dlorenc on 7 Nov 2017

👍2

Product manager for Fusion here... Can we help?

mikeroySoft on 20 Jan 2018

Please check discussion on the PR. We, Minishift and minikube, discussed
that it might be a better idea to move the driver to a different
organisation we have set up. Details are on the PR. This will make
maintenance easier as a shared effort.

Link to the comment:
https://github.com/kubernetes/minikube/pull/2118#issuecomment-358735768

We will still setup CI, but with a fixed/stable version for minikube. While
we will try to create CI for each PR in the org for development purpose.

The reasoning is that each driver in minikube is expected to have a certain
quality that we can not guarantee at the moment. We have limited bandwidth,
so we rather give this responsibility to the developers of the driver.

gbraad on 20 Jan 2018

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

fejta-bot on 20 Apr 2018

/remove-lifecycle stale

RobbieJ on 3 May 2018

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

fejta-bot on 1 Aug 2018

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-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

fejta-bot on 31 Aug 2018

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

fejta-bot on 30 Sep 2018

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.