Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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 this issue Jan 26, 2024 · 2 comments

Comments

@kcq
Copy link
Contributor

kcq commented Jan 26, 2024

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
Copy link
Owner

fsouza commented Feb 12, 2024

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
Copy link
Contributor Author

kcq commented Feb 12, 2024

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants