Find new home for docker-machine KVM driver

[dhiltgen]

For various reasons I no longer use this driver during my day-to-day dev work, and given the lack of CI for builds and test automation, this makes it challenging to keep up with incoming PRs. I tried to keep up for a while but at this point to be fair to the community of folks who are using this driver, I'd like to explore if there are other folks out there that are actively using it and would be interested in taking over the project so we can be more responsive to incoming PRs.

\cc @karmab @nkiesel @op @mfriedenhagen @gbraad @mykaul @zakame @petrkotas @HartS @flavio @jcodybaker

[afbjorklund]

Unfortunately, docker-machine doesn't want it upstream either: docker-archive-public/docker.machine#4101

[zakame]

I can take this up as I use it for my $WORK. I also helped pull a few bit from this for the minikube kvm2 driver earlier.

I think having the KVM driver separate from docker-machine dist is fine, it is probably better because there could be a focus on improving KVM-specific features rather than just keeping up with d-m churn.

[gbraad]

FYI, Minikube: @r2d4 @aaron-prindle, Minishift: @praveenkumar, @LalatenduMohanty

[gbraad]

I would suggest to move it under a combined account/organization instead of a single developer, as several projects depend on this driver

Since there are several drivers now, maybe this can be part of the organization. such as xhyve/hyper-kit, etc? WDYT?

• machine-drivers/kvm
• machine-drivers/docker-machine-kvm
• etc.

note: /me suggest avoiding the use of Docker in the name due to legal reasons

[gbraad]

@afbjorklund correct, libmachine is in a maintenance mode and will not take any new functionality.

[praveenkumar]

We as part of https://github.com/minishift/ use this driver day in day out and be happy to put in the same org and provide required permissions.

[LalatenduMohanty]

Agree with @gbraad @praveenkumar we can maintain it as we use it actively in Minishift.

[zakame]

Yep I agree putting it under an org is better, the more co-maintainers the better 💪

[afbjorklund]

Since we are not allowed in the "libvirt" group, we used the "qemu" driver instead. Would be nice if this new place would have room for both ? Not sure how long the drivers can live without active support from machine (case in point: ports), but I think they still be useful for some time to come...

[afbjorklund]

We use this: docker-archive-public/docker.machine#4034

[gbraad]

@afbjorklund I spoke with @veillard (DV) about this too (my manager) related to the libvirt and qemu choice. There are some things we can discuss over time, but as suggested in this case, a general org seems the way to go?

[afbjorklund]

@gbraad : yeah, that sounds good!

[gbraad]

We briefly discussed (@afbjorklund, @r2d4, @LalatenduMohanty, @praveenkumar and @gbraad)... since we had a sync-up meeting related to minikube-minishift we made this part of a topic to talk about.

We all agreed on the idea to place it in a separate organization namespace, as this reflects more of the community-based nature of maintenance and is also easier to grant permissions to people to maintain the codebase. I went ahead and created: https://github.com/machine-drivers If you think this name is not OK, just let me know and we can change it... but to us this reflected a neutral approach. I already added several people to the org, including @zakame and those on the meeting. If I need to add more people, just let me know.

Thank you, @dhiltgen We will give the driver a good home and we will keep maintaining it.

[SvenDowideit]

👍 to https://github.com/machine-drivers ! @gbraad do you have a process in mind for adding other drivers? I needed a non-libvirt qemu driver, so https://github.com/jigtools/docker-machine-driver-qemu was born, but with an umbrella group, we should be able to get libmachine going again.