Fix docker api proxy smoke-tests after docker-py change (on 1.0 branch)

[bboreham]

Docker-py was changed upstream to run using a test harness Pytest.

Also I have seen some failures due to the 'busybox' image not being found on the test host.

[bboreham]

I have no idea why particular test is failing on 1.0 and not on master:

>       self.assertEqual(container_log_config['Config'], {})
E       AssertionError: None != {}

[rade]

self.assertEqual(container_log_config['Config'], {})

So that's in test_valid_no_config_specified, which was introduced recently.

[rade]

@paulbellamy can you look into that "breaks on 1.0, fine on master" issue? I've spent a few minutes checking whether anything significant has changed between 1.0 and master in how we manipulate the HostConfig (which is where the log config resides) on create, but it all looks pretty similar.

[paulbellamy]

I believe it is because in the createContainerInterceptor we decode, modify, and re-encode the request. Because go has limited nil/zero semantics the go dockerclient encodes the request slightly differently. Sending a null instead of {}.

To completely avoid this we would have to refrain from parsing the request using the go docker client, and just parse it as a set of maps (which would all-around be safer anyway). However that is a bigger change than should go in 1.0.

[rade]

I believe it is because in the createContainerInterceptor we decode, modify, and re-encode the request.

That's exactly the kind of thing I was looking for in the proxy code, but afaict we do that in both 1.0 and master, so it doesn't explain the difference in behaviour.

[paulbellamy]

There is no change. It also fails on master, but master's test matching regex is wrong.

[rade]

master's test matching regex is wrong

File an issue.

To completely avoid this we would have to refrain from parsing the request using the go docker client, and just parse it as a set of maps (which would all-around be safer anyway).

Is that what docker itself does?

I do rather wonder whether the test is too strict, or even just wrong. Note that it actually sends None and expects to get back {}. Which is weird.

[paulbellamy]

Even when you say None python still sends {}.

[paulbellamy]

Edit: disregard this, was not what was happening.

[rade]

So how do the docker client and docker itself differ in decoding the request?

[paulbellamy]

Hold on actually. Needs more research..

[paulbellamy]

Ok, have added a temporary fix for these tests, where we don't replace the request body unless we modify it.

Opened #1371 to deal with the underlying issue, which is a bigger change than I would like for 1.0.

[rade]

@paulbellamy @bboreham I have made a couple of small tweaks. Please check they are ok. Then squash and merge and do the 1.0->master merge. All LGTM :)