search

machine-drivers / machine

Machine management for a container-centric world
Apache License 2.0
25 stars 16 forks source link

docker-machine is closed, so if we want it to continue, we need to start releasing #4

Closed SvenDowideit closed 5 years ago

SvenDowideit commented 6 years ago

see https://github.com/docker/machine/issues/4537

I'm also wondering if toolbox is needed too - there are users that don't use hyper-v, or simply have different goals :/

gbraad commented 6 years ago

At the moment machine is more important to us... and not even in binary form (we only compile and link to the library; same for minikube)

@praveenkumar @LalatenduMohanty @dlorenc @aaron-prindle @r2d4 WDYT?

LalatenduMohanty commented 6 years ago

At this moment docker machine as library is important for us. May be we can release the binary too (in future if we get some new features).

gbraad commented 6 years ago

at the origin's repo they only used:

which is easy to replicate.

gbraad commented 6 years ago

ALso, should this remain a fork... or should we break this reference and re-import as a 'new' project?

praveenkumar commented 6 years ago

At the moment machine is more important to us... and not even in binary form (we only compile and link to the library; same for minikube)

Right for us (minishift + minikube) are going to use as library but if they are closing the project down then might be in future we need to build binary out of it also.

gbraad commented 6 years ago

to use Circle CI for macOS we need to send an email, and for AppVeyor we need a dedicated account

gbraad commented 6 years ago

@praveenkumar it depends. do we really want to use a *-machine command to control the state of... eh, what? We do not really integrate well with the machine environment at all, as a create using this tool does not use our specific provisioners. To make it even work together, you need to do: https://github.com/kubernetes/minikube/issues/2681

afbjorklund commented 6 years ago

Seems like continuing Docker Machine and Docker Toolbox is a huge task, if not even Docker Inc. wants to do it... Better focus on libmachine, perhaps even in a separate git repository (like with the kvm2 driver) ?

Like it says, that mcndirs should probably be removed:

vendor/github.com/docker/machine/libmachine/provision/boot2docker.go:   // TODO: Ideally, we should not read from mcndirs directory at all.
vendor/github.com/docker/machine/libmachine/provision/boot2docker.go:   b2dutils := mcnutils.NewB2dUtils(mcndirs.GetBaseDir())

And the drivers are handled a bit differently, by minikube...

gbraad commented 6 years ago

libmachine is already forked and has been setup for CI

On Mon, Jul 30, 2018 at 10:13 PM, Anders Björklund <notifications@github.com

wrote:

Seems like continuing Docker Machine and Docker Toolbox is a huge task, if not even Docker Inc. wants to do it... Better focus on libmachine, perhaps even in a separate git repository (like with the kvm2 driver) ?

Like it says, that mcndirs should probably be removed:

vendor/github.com/docker/machine/libmachine/provision/boot2docker.go: // TODO: Ideally, we should not read from mcndirs directory at all. vendor/github.com/docker/machine/libmachine/provision/boot2docker.go: b2dutils := mcnutils.NewB2dUtils(mcndirs.GetBaseDir())

And the drivers are handled a bit differently, by minikube...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/machine-drivers/machine/issues/4#issuecomment-408878021, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAHZhjFcpS0bGGufZoyGHvKqrNesYWPks5uLxSTgaJpZM4VQc61 .

--

Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ]

afbjorklund commented 6 years ago

@gbraad : also including the commands and everything, right ? (i.e. this repo)

gbraad commented 6 years ago

What do you mean with commands? We are unlikely to release a binary (app) from this repo.

afbjorklund commented 6 years ago

Ah, right. I thought that @SvenDowideit suggested doing just that (making new releases of docker-machine, and even the rest of the toolbox too ?)... But that minikube only needs libmachine (and mcndirs and version, per above).

Which means that theoretically it could use a different "libmachine-only" version of the repository, without the commands and without the cloud drivers. That would make it more of a outright fork, then just continuing hosting the old repository.

gbraad commented 6 years ago

right, we could create a new binary, but it would like have to be under a new name, like 'container-machine', plus removal of all the trademarks and mention of Docker.

We will discuss this soon with Minikube; @praveenkumar might be able to invite you too

SvenDowideit commented 6 years ago

tbh, I was thinking that we'd just call it machine - but its been quite a long time since I actually used machine

gbraad commented 6 years ago

I am fine either way... for me it is about continued maintenance and possibly some refactoring.

afbjorklund commented 6 years ago

It seems like the v0.15.0 tag is missing from this repo ? https://github.com/machine-drivers/machine/releases/tag/v0.15.0

Not sure if the changes to the PR template are desired ? https://github.com/machine-drivers/machine/commit/4f225c95439fdf89e9ef071955d4a505d2b58329

Thank you for your interest in contributing to Docker Machine! Please note that the project is now in MAINTENANCE MODE, meaning we will no longer review or merge PRs that introduce new features, drivers or provisioners. We will continue to consider and review proposed bug fixes and dependency upgrades when appropriate.

Thank you for your understanding.

But it would be nice to make things clear about support level, if it is "only" libmachine and drivers ?

There is already quite a difference in Docker versions, between boot2docker and minikube/minishift.

dlorenc commented 6 years ago

What did we decide here? I think we should probably drop the releases and binaries and make it clear that this is only about supporting libmachine and drivers.

afbjorklund commented 6 years ago

@dlorenc : I think that makes sense, and it seems like Docker will still maintain the old binaries for people who want their "legacy" solution (don't run Win or Mac)...

Do you need to actually change something in this repository, or is it just making it clear in the README or something - that is only intended as a library dependency ?

dlorenc commented 6 years ago

I'd like to make it clear in the readme, close this issue and then potentially delete the code/deps we no longer need.

afbjorklund commented 6 years ago

Did a short list previously (above), it looked straight-forward - except for that "mcnutils" thingie.

It could potentially be a future problem, if people want to use the drivers provided by this repository for the original machine implementation (docker) that is "frozen" in specificaiton if the library implemention (machine-drivers) drifts away from that by adding features or continuing to evolve. But right now, it's "close enough" that they should probably work for both ? There's already a selection of ISO images...

dlorenc commented 6 years ago

Yeah changing the interface will be troublesome. Your proposal of what to delete makes a lot of sense.

dlorenc commented 6 years ago

ALso, should this remain a fork... or should we break this reference and re-import as a 'new' project?

I think this makes sense - any idea how to break the reference?

afbjorklund commented 5 years ago

@SvenDowideit : The upstream project is once again making some releases, and there are currently no commits here that aren't also merged there... So maybe it should just be rebased, and synced with the upstream 'master' ?

There are no changes (compared to v0.16.1) to the API, only to the bundled drivers themselves... Currently the machine-drivers/master is in sync with docker/v0.16.0^, with only one backported commit.

afbjorklund commented 5 years ago

Leaving this at v0.16.1 (now with two backported commits)