Smarter API version handling #1060
Comments
|
@rhuss : Could you please give some code pointer related to this? |
|
During initialization we check which features are used and then calculate the minimal version required: If nothing special is used its, the default of 1.18 for now.The docker client will be created with this version Then, for each request this version is send to the daemon Actually when we get back an error that indicates that's a version mismatch like in the first post, we should adapt the minimal version to that provided in the response header. Alternatively, and actually i like that better, we could send a single request to some version endpoint and pick up the api version. If this version is larger then our minimal version we just use that for our minimal version. otherwise we throw an error that we can't talk to the daemon (as our minimal version is higher of what the daemon provides). |
Send a test request to the Daemon, and check whether it succeeds. In the return response there's a header Api-Version: which holds the actual Docker daemon version. If this test request because of a too low version, we can just pick up that version and use it as minimal version for us.
Send a test request to the Daemon, and check whether it succeeds. In the return response there's a header Api-Version: which holds the actual Docker daemon version. If this test request because of a too low version, we can just pick up that version and use it as minimal version for us.
Send a test request to the Daemon, and check whether it succeeds. In the return response there's a header Api-Version: which holds the actual Docker daemon version. If this test request because of a too low version, we can just pick up that version and use it as minimal version for us.
Send a test request to the Daemon, and check whether it succeeds. In the return response there's a header Api-Version: which holds the actual Docker daemon version. If this test request because of a too low version, we can just pick up that version and use it as minimal version for us.
Send a test request to the Daemon, and check whether it succeeds. In the return response there's a header Api-Version: which holds the actual Docker daemon version. If this test request because of a too low version, we can just pick up that version and use it as minimal version for us.
Send a test request to the Daemon, and check whether it succeeds. In the return response there's a header Api-Version: which holds the actual Docker daemon version. If this test request because of a too low version, we can just pick up that version and use it as minimal version for us.
Send a test request to the Daemon, and check whether it succeeds. In the return response there's a header Api-Version: which holds the actual Docker daemon version. If this test request because of a too low version, we can just pick up that version and use it as minimal version for us.
Send a test request to the Daemon, and check whether it succeeds. In the return response there's a header Api-Version: which holds the actual Docker daemon version. If this test request because of a too low version, we can just pick up that version and use it as minimal version for us.
|
I know this is closed, but I just started using this plugin against an older Docker version (1.12.5, with Api-Version 1.24), and the fix here isn't good. Using 0.27.1 works OK. The issue is that Since there is already code in |
|
@JoshLitt : ah, apologies for the inconvenience. You're right, this change wasn't supposed to break backward compatibility. We should also handle the case when there is no apiVersion specified in header |
Since Api-Version header was introduced in 1.25, we should send a minimal api-version rather than just sending null. See this comment: fabric8io#1060 (comment)
Since Api-Version header was introduced in 1.25, we should send a minimal api-version rather than just sending null. See this comment: fabric8io#1060 (comment)
) Since Api-Version header was introduced in 1.25, we should send a minimal api-version rather than just sending null. See this comment: #1060 (comment)
|
@JoshLitt should be fixed now with the next release (see later PR merged) |
|
I just ran into same issue with d-m-p 0.28 to 0.30 running against latest docker windows How do fix this? my apology for not seeing the obvious in this discussion |
Description
As described in fabric8io/fabric8-maven-plugin#1200 the minimal version 1.18 used by d-m-p gets rejected for newer Docker daemons (e.g. those having 1.35).
Actually we are compliant with the newer versions (its a minimal version after all), so I see two solutions:
If possible, we don't send an API version. However when we use features which require a minimal version of 1.21 this still will still break.
We send a test request to the Daemon, and check whether it succeeds. In the return response there's a header
Api-Version:which holds the actual Docker daemon version. So if this test request because of a too low version, we can just pick up that version and use it as minimal version for us.The text was updated successfully, but these errors were encountered: