Missing documentation for local builds about docker-machine-hypriot

[benediktarnold]

The solution was as simple as:

go get github.com/docker/machine/libmachine/drivers/plugin
go get github.com/hypriot/docker-machine-hypriot

But I don't understand the second go get. Why should I go get the repo I have checked out in the current working dir?

[StefanScherer]

@benediktarnold Thanks for the solution. I think you have cloned the repo outside of your GOPATH. The dependencies normally are looked up in GOPATH as shown in the output above.
So the second go get just clones the sources again in the GOPATH.

The idea with the Makefile + Dockerfile is that nobody has to setup go and the whole development environment for GO directly on the laptop ;-)

BTW: I want to make some progress with this repo as I also want to use it with latest docker-machine again :)

[benediktarnold]

I think I have to read about go development at all ;-)
Found a documentation on how to build locally in the docker-machine project: https://github.com/docker/machine/blob/master/CONTRIBUTING.md

I like the idea with the build inside the container, but if you need a binary for OSX this does not work. Maybe cross compiling will do the trick, but I need to read about this as well ;-)

[benediktarnold]

@StefanScherer I tried to setup a machine with this driver against hypriot 0.6.1 (I don't think the version matters) and I was only successful using my docker-machine fork with a custom provisioner https://github.com/benediktarnold/machine/blob/hypriot/libmachine/provision/hypriot.go

This is basically a copy of the debian provisioner with overlay as default Storage driver and a changed name that gets compared with the os-release ID, during search for the correct provisioner.

I don't like this heavily copy and pasted code but in a first place it works.

[StefanScherer]

@benediktarnold Thanks for not giving up ;-) Just to understand it right, you need to build docker-machine itself with your fork to have the plugin up and running?

That's what I stopped 2 months ago, but hadn't the time to investigate it yet. The docker-machine 0.4.1 fork where no driver plugins existed yet also has a provisioner for hypriot.
And what I want to find out is whether a driver plugin also can add/register a provisioner from the driver plugin binary.

If that is possible that would be great to write such an external plugin. If not we have to send a PR to upstream docker/machine repo to add the provisioner code there. Or there should be external provisioner plugins as well...

[StefanScherer]

The docker-machine 0.4.1 changes for hypriot are here:

• https://github.com/hypriot/machine/blob/v0.4.1-hypriot/drivers/hypriot/hypriot.go
• https://github.com/hypriot/machine/blob/v0.4.1-hypriot/libmachine/provision/hypriot.go

But with the external driver plugin I think even registering a provisioner in the external driver plugin won't work as the provision steps are called from the docker-machine main binary and thus able to talk over RPC with the driver plugin.

I haven't seen any external docker-machine driver plugin that also needs additional provisioners as they "only" have to drive another hypervisor or cloud with an Intel based OS that is handled with the main binary.

[benediktarnold]

Yes and it turns out that I only need the changes in docker-machine ;-) No need for a special driver. It works great with the generic driver.

Thanks for the links to your provisioner. I merged into my branch and made it compatible with the latest docker-machine master branch. It is way better than my initial provisioner which was basically a rebranded debian provisioner. You can find my fork here https://github.com/benediktarnold/machine/tree/hypriot

Unless docker-machine has plugin support for provisioners we need to make a PR.

[StefanScherer]

@benediktarnold That's great! Probably we should update some parts of the code to be more similar to upstream provisioners.

But a PR could be difficult to be merged as what I have seen with the photon provisioner. There is no official ARM docker deb package yet so linking to our packagecloud to fetch an "inoffical" docker binary would be a problem in upstream, I think.