search

dhiltgen / docker-machine-kvm

KVM driver for docker-machine
Apache License 2.0
376 stars 111 forks source link

Find new home for docker-machine KVM driver #67

Open dhiltgen opened 6 years ago

dhiltgen commented 6 years ago

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 commented 6 years ago

Unfortunately, docker-machine doesn't want it upstream either: https://github.com/docker/machine/issues/4101

zakame commented 6 years ago

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 commented 6 years ago

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

gbraad commented 6 years ago

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?

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

gbraad commented 6 years ago

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

praveenkumar commented 6 years ago

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 commented 6 years ago

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

zakame commented 6 years ago

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

afbjorklund commented 6 years ago

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 commented 6 years ago

We use this: https://github.com/docker/machine/pull/4034

gbraad commented 6 years ago

@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 commented 6 years ago

@gbraad : yeah, that sounds good!

gbraad commented 6 years ago

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 commented 6 years ago

👍 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 commented 6 years ago

@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 commented 6 years ago

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 https://github.com/dhiltgen/docker-machine-kvm/issues/67#issuecomment-358844840, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHpYa7tEapPXAWcRZ6Z7Myzc2ulCdVyks5tL_jqgaJpZM4RgBny .

LalatenduMohanty commented 6 years ago

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.

WDYT?

gbraad commented 6 years ago

@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 commented 6 years ago

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

LalatenduMohanty commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 https://github.com/dhiltgen/docker-machine-kvm/issues/67#issuecomment-358877522, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHpYS-rNSR8qPxq04DcgFfFnw-ZCqMqks5tMDQjgaJpZM4RgBny .

SvenDowideit commented 6 years ago

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 commented 6 years ago

@dhiltgen would you agree to moving your repo to machine-drivers, and do you have any comments on https://github.com/machine-drivers/discussion/issues/2 ?

gbraad commented 6 years ago

@SvenDowideit thanks for creating the new issues and discussion.

gbraad commented 6 years ago

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 => image 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 commented 6 years ago

ok, stuffit, doing it the hard way

SvenDowideit commented 6 years ago

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

afbjorklund commented 6 years ago

@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 commented 6 years ago

easy rename at this point - one mo :)

SvenDowideit commented 6 years ago

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

mfriedenhagen commented 6 years ago

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

SvenDowideit commented 6 years ago

@mfriedenhagen done?

mfriedenhagen commented 6 years ago

Thanks, @SvenDowideit

olastor commented 2 years ago

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 commented 2 years ago

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