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

[gbraad]

@SvenDowideit at the moment we do not have such a 'process', but let's consider creating a mailinglist or some other means to discuss. WDYT?

[mfriedenhagen]

hello, good to know that the software will be maintained, github group name sounds good. What about an umbrella/organisational github project to cover such discussions in issues instead of a mailing list? Then overview of "open" requests is easier, you have a place for a readme to explain the process, an easy mechanism for voting etc. Regards Mirko -- Sent from my mobile Am 19.01.2018 03:07 schrieb "Gerard Braad" <notifications@github.com>:

…

@SvenDowideit <https://github.com/svendowideit> at the moment we do not have such a 'process', but let's consider creating a mailinglist or some other means to discuss. WDYT? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHpYa7tEapPXAWcRZ6Z7Myzc2ulCdVyks5tL_jqgaJpZM4RgBny> .

[LalatenduMohanty]

What about an umbrella/organisational github project to cover such discussions in issues instead of a mailing list? Then overview of "open" requests is easier, you have a place for a readme to explain the process, an easy mechanism for voting etc.

I would suggest few things which has worked for us i.e. https://github.com/minishift/minishift.

• Depending upon how many maintainers we have per repository we can ask for approval (LGTM) from at-least two maintainers for first couple of months. It would help to build up a culture around what would be the quality of a PR. But repositories with one maintainer would need not have this process.

• There should an issue created for each pull request. Because PR can be closed and recreated but an issue will be persistent in nature. It helps make an discussion to reach to an conclusion which can be referred later. Commit should refer to the issue number as it will help to find out related discussions from a commit.

• Also as a general practice , code changes should accompanied by unit tests, integration tests (if any), documentation changes if applicable. It is applicable to all contributors including the maintainers.

• We should setup continuous integration to test the incoming PRs.

WDYT?

[gbraad]

@LalatenduMohanty I think in this case @SvenDowideit meant; who decides, or how to add a repo to the organisation. especially in his case, as he has a qemu-based driver, this is something similar to @afbjorklund proposed. It would mean, however comes first? I think in this case we need to decide on a strategy.

@ all,
For the KVM2 driver from minikube we have already preliminary decided to have the changes being incorporated in the original KVM driver. In case of deviation that is breaking, we would keep a 'legacy' branch, but we will try to refactor to include the changes from minikube and minishift's end.

The same would be for the drivers for xhyve and hyperkit, such as maintained by @zchee and worked on by @dlorenc. I think for this some discussion is needed, but it would be great if this can also find a place under this org.

[gbraad]

@mfriedenhagen actually, having a 'general' or whatever repo crossed my mind, but this is also feels messy to me. Anyone have a suggestion?

[LalatenduMohanty]

@LalatenduMohanty I think in this case @SvenDowideit meant; who decides, or how to add a repo to the organisation. especially in his case, as he has a qemu-based driver, this is something similar to @afbjorklund proposed. It would mean, however comes first? I think in this case we need to decide on a strategy.

I misunderstood. Then we need have a public mailing list or need a repository where issues can be opened to create/move a repository to the https://github.com/machine-drivers where folks can give thumbs up or down.

[afbjorklund]

@gbraad : it is indeed the same driver, based on the excellent previous work by @fventuri and @SvenDowideit - as can be seen from https://github.com/afbjorklund/docker-machine-driver-qemu .
I was under the impression that neither was using it anymore, so we extended it for additional purposes, but would gladly like to merge them - or fix any issues/conflicts, under this new home/organisation.
(it shouldn't be worse than e.g. merging KVM/KVM2, and we need to fix some libmachine usage too - when the driver was written it was only for docker-machine and didn't consider libmachine concerns)

[mfriedenhagen]

Well, I do not think this very messy. You may easily watch all new issues or subscribe to those you are interested in. Closing an issue makes it clear to new visitors, that the discussion was "finalized". Users have a one stop solution for requests, labeling is helpful for sorting and you may use markdown for formatting. Mailing lists on the other hand tend to have more spam, you firstly need to find them (or document). Not sure if I could help very much anyways as my golang experience is approx. < 10 days, being a Java and Python guy mostly. -- Am 19.01.2018 07:20 schrieb "Gerard Braad" <notifications@github.com>: @mfriedenhagen <https://github.com/mfriedenhagen> actually, having a 'general' or whatever repo crossed my mind, but this is also feels messy to me. Anyone have a suggestion? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHpYS-rNSR8qPxq04DcgFfFnw-ZCqMqks5tMDQjgaJpZM4RgBny> .

[SvenDowideit]

ok, in the interests of getting somewhere, I've made a discussion repo - https://github.com/machine-drivers/discussion

lets move over there, and point others to it - we can delete/refactor if it becomes messy :)

[SvenDowideit]

@dhiltgen would you agree to moving your repo to machine-drivers, and do you have any comments on machine-drivers/discussion#2 ?

[gbraad]

@SvenDowideit thanks for creating the new issues and discussion.

[gbraad]

Can we transfer this repository to the new machine-drivers organization? https://github.com/machine-drivers/ VMware, qemu and hyperkit are already there... would prefer to see a transfer as it preserves the issue tracker.

https://github.com/dhiltgen/docker-machine-kvm/settings =>
and then create a personal clone (with a redirect notice in the description). For more information: https://help.github.com/articles/about-repository-transfers/

[SvenDowideit]

ok, stuffit, doing it the hard way

[SvenDowideit]

I've pushed the master from here to https://github.com/machine-drivers/kvm

[afbjorklund]

@SvenDowideit : I thought we said that the new name would be "libvirt" (not kvm, not kvm2) ?
And that the name of the repo was going to be the same as the program, including the "driver".

i.e. docker-machine-driver-libvirt

Thanks for making things happen, though!

[SvenDowideit]

easy rename at this point - one mo :)

[SvenDowideit]

and now its https://github.com/machine-drivers/docker-machine-driver-libvirt

[mfriedenhagen]

@SvenDowideit, would you mind pushing the old tags as well?

[SvenDowideit]

@mfriedenhagen done?

[mfriedenhagen]

Thanks, @SvenDowideit

[olastor]

Could you please add a notice to the README about the new driver repo? I had to find this issue and read through it to find out, others would appreciate if you mark this repo as legacy and link the new one I think.

[afbjorklund]

Archiving the repo would also work, that is what happened to docker machine (and boot2docker).
Ultimately, it is going to need home - for all of it...