We shouldn't be modifying unintended fields when creating containers/execs

[paulbellamy]

The side effect of decoding/encoding the request body with go-dockerclient, is that it can encode it differently than the client had meant to. This caused a failure in #1367, and could generally cause mangling of requests (e.g. if the fields present in go-dockerclient disagree with the docker server).

We should use a less invasive way of modifying the incoming requests.

Specific instance of this bug is the failure in test_valid_no_config_specified

[rade]

I am reluctant to make such a significant change in 1.1 so close to a release, though I see you are already half-doing that in #1376.

Would updating the go docker client to the latest version - which iirc happens anyway during the release process - ameliorate this issue?

[paulbellamy]

I agree it's a bit big for 1.1.

Updating the go docker client may temporarily help, but won't solve other issues (like with volume drivers). The client makes a few simplifying assumptions about the format of the data which are approriate for a client, but not specific enough for the server.

[rade]

won't solve other issues (like with volume drivers)

Oh. Really? The most recent go docker client ignores the volume driver settings?

[paulbellamy]

Ah, no, looking again, it does handle them. It's more that longer-term when the API changes the go client (being stricter) will break more often.

[rade]

could somebody please check that #1378 gets fixed when running with a proxy built with the latest golang docker client?

[bboreham]

On it.

[bboreham]

It does not get fixed; go-dockerclient does not yet know anything about the new VolumeDriver parameter.

[bboreham]

So I submitted fsouza/go-dockerclient#367

[bufdev]

@bboreham let me know if there's anything else missing on the volumes side of go-dockerclient, I think we might be both trying to accomplish similar things fsouza/go-dockerclient#362

[bboreham]

@peter-edge ok, but we're reacting to a user issue #1378; I eyeballed the Docker change to look for other missing fields but don't have any good basis to know for sure.

[errordeveloper]

From testing latest change (32a82f2) on Kubernetes, one rather critical issue popped-up. Essentially what happens is that we somehow end-up marshalling integers in scientific notation and the parser on the other end fail with json: cannot unmarshal number 5.24288e+07 into Go value of type int64.

[rade]

@errordeveloper Please open a separate bug for that!

[errordeveloper]

Please open a separate bug for that!

#1390