Propogate given configuration to plugin servers

[nathanleclaire]

Closes #3181

cc @dgageot for review -- this one is a bit tricky and we need to define what our expectations are around API breakage / versioning. Because this would introduce a call to a RPC endpoint which won't be present in all cases. I'm open to other ideas if you have them of course.

I guess my feeling is that in this case, we are creating a brand new method, and if we try to call it but it's not there, nothing is different than it was before (when the plugin servers weren't getting the propagated config information anyway) and we can keep moving forward. It doesn't break existing plugins (shouldn't at least), just adds a new method.

Signed-off-by: Nathan LeClaire nathan.leclaire@gmail.com

[nathanleclaire]

What do you think best way to unit test this is? Through runCommand? RegisterPlugin?

[nathanleclaire]

Heh... the 3rd party plugin compatibility test I was adamant about is working as intended 😛 wonder if I should submit a change to the upstream repo as well

[nathanleclaire]

WDYT @dgageot ? Should I add to https://github.com/docker/docker-machine-driver-ci-test/blob/master/driver.go ? Or should we adopt a different approach?

[dgageot]

@nathanleclaire adding a function that every driver should implement is really cumbersome, right?

[nathanleclaire]

@nathanleclaire adding a function that every driver should implement is really cumbersome, right?

Yes, in this case however it is not needed to make an update to the Driver itself. The problem is around adding a new method to the RPCServerDriver API (which mostly wraps a Driver, but also has some other methods on top such as GetVersion for API management layer). If you were a 3rd party plugin maintainer you'd simply have to re-compile with the latest Machine master and do a new release of your binary.

Still, I'm not sure it's the best approach exactly, and might end up throwing in a different, hackier (but more compatible) solution for the release.

[claygriffiths]

What's the status of this?

Being able to use --native-ssh would most likely help for issues such as:

• Failed to create docker-machine - ssh error  #4305
• [SSH] - Unable to start Kitematic #3955
• docker-machine can't create boot2docker vm on Windows 10 #2737