Allow docker client to negotiate the API version with the server

[bainsy88]

The version is currently hardcoded which is causing the issue documented here - #2259

Decided adding a unit test wasn't feasible as as the version would change each time we pulled in a new docker client and as long as it negotiates a version that works I suspect we don't care what that exact version is.

[TomSweeneyRedHat]

The change Looks good for what you're trying to do. I'm just a bit hesitant to drop the test. I'd lean towards bumping the default version to 1.24 instead. @mtrmac WDYT?

Regardless, TYVM for the PR @bainsy88

[TomSweeneyRedHat]

This is a different approach to solving the problem as #2258

[bainsy88]

Ah I hadn't noticed the other PR which beat me to it. Happy to go with the other one given it already had tests and that was a concern with this change

[mtrmac]

Thanks!

• Version negotiation ends up being better than hard-coding; with negotiation, there is a chance for the client & server to use a mutually-intelligible version larger than 1.24 (and version negotiation exists since 1.24, so hard-coding a requirement for 1.24 without negotiation is no less restrictive. Opting into version negotiation does interoperate with <1.24… using the 1.24 semantics. So version negotiation is at least as compatible as hard-coding 1.24, and more compatible long-term).
• We do need to actually enable version negotiation to benefit that way, though. This PR does not currently do that, AFAICT. (And the Docker CLI does opt into version negotiation, which is another reason to do the same thing.)
• (The history is that the code was originally written when there was no version negotiation (in the client libraries at least); there is a fairly extensive discussion about the trade-offs at the time in Issue #327 Creating Docker client from env settings #328 , but just during that time version negotiation was being added to the client libraries…)
• I’m fine with removing the tests checking the client’s properties. The client’s configuration applied based on the options is, for the most part, not inspectable, we just have to trust that the client initialization would fail if we gave it nonsensical instructions.

[bainsy88]

I have built skopeo off this code and added some additional debug so can see the client version is 1.44 but it negotiates it down to 1.43 when I run against Docker 24.0.7

[mtrmac]

Confirming that code from this PR works with both Docker 24 and 25.

Alternatively, a workaround:

# cat /etc/systemd/system/docker.service.d/version.conf 
[Service]
Environment=DOCKER_MIN_API_VERSION=1.22

[mtrmac]

Thanks, to both @bainsy88 and @dpeckett !

[TomSweeneyRedHat]

Yes, @bainsy88 and @dpeckett TY both very much for this discussion and change.