search

fsouza / go-dockerclient

Go client for the Docker Engine API.
https://pkg.go.dev/github.com/fsouza/go-dockerclient?tab=doc
BSD 2-Clause "Simplified" License
2.18k stars 565 forks source link

With the Latest Docker Engine v25.x the Version Selection Magic Based on the Call Option 'ver` Tags Results in Failing Calls #1030

Open kcq opened 9 months ago

kcq commented 9 months ago

The Docker Engine v25.0 release deprecates the APIs below version 1.24 ( https://docs.docker.com/engine/deprecated/#deprecate-legacy-api-versions ).

The current dynamic version selection logic causes failures if you haven't configured an options field in the API call you are making with a big enough 'ver' tag value.

We can use (c *Client) BuildImage(opts BuildImageOptions) as an example: https://github.com/fsouza/go-dockerclient/blob/main/image.go#L537

It calls queryStringVersion to figure out the minimal API version based on the provided BuildImageOptions fields. Then it calls pathVersionCheck, which creates buildURL based either on the explicitly configured API version when the client was created or the minimal API version guessed by queryStringVersion.

If you set the Name and ForceRmTmpContainer fields in BuildImageOptions queryStringVersion will guess the minimal version to be 1.12 (because the ver tag for the ForceRmTmpContainer field in BuildImageOptions is set to 1.12 ). Then pathVersionCheck will create an API path with 1.12 if you don't create a versioned Client explicitly.

The go-dockerclient claims that if you don't specify an API version then the latest API version will be used, but it's not really the case here.

@fsouza curious what you think about this behavior and how you'd prefer to address it in the library. The docker/moby client has the NegotiateAPIVersion call ( https://github.com/moby/moby/blob/v25.0.1/client/client.go#L294 ) that's potentially relevant for this.

fsouza commented 9 months ago

Thanks for opening this issue and apologies for the delayed response.

I think we can try to adopt the same behavior as the official SDK. Also, I think it's kind of an accident that we don't use the latest version when it's not specified. I'm thinking of trying to fix that, but also understand that that has the potential to break many things. I'll poke around in the next couple of days!

kcq commented 9 months ago

Both sound like a good idea. For the second enhancement how about adding a client option to toggle the behavior to get latest version or to have the original version selection magic? Thank you for the library and no worries about the delays. Pretty sure you have enough on your plate and the open source work is personal time :)