- Add a VolumeUpdateResult output struct
- Move the swarm version argument to the options, to align
with other swarm-related methods.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The API now includes this information per record, and clients can
get this information using the `Ping` method if needed as fallback.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adds a per-stats OSType field to allow handle the platform-specific fields.
Before this change, the client had to get the OSType field from the server's
API response header and copy it to each record.
Older daemon versions don't have this field, so the client still needs to
handle fallbacks.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The JSON field was added in [moby@9fd2c0f], to address [moby#19177], which
reported an incompatibility with Classic (V1) Swarm, which produced a non-
standard response;
> Make docker load to output json when the response content type is json
> Swarm hijacks the response from docker load and returns JSON rather
> than plain text like the Engine does. This makes the API library to return
> information to figure that out.
A later change in [moby@96d7db6] added additional logic to make sure the
correct content-type was returned, depending on whether the `quiet` option
was set (which produced a non-JSON response). This caused inconsistency in
the API response, and [moby@2f27632] changed the endpoint to always produce
JSON (only skipping the "progress" output if `quiet` was set).
This means that the "load" endpoint ([`imageRouter.postImagesLoad`]) now
unconditionally returns JSON, making the `JSON` field fully redundant.
We should consider deprecating the "quiet" option, as it's really the client's
responsibility to show or hide progress-bars, but we can do this separately.
This patch removes the JSON field, as it's redundant, and the way it handles
the content-type is incorrect because it would not handle correct, but different
formatted response-headers (`application/json; charset=utf-8`), which could
result in malformed output on the client.
[moby@9fd2c0f]: 9fd2c0feb0
[moby#19177]: https://github.com/moby/moby/issues/19177
[moby@96d7db6]: 96d7db665b
[moby@2f27632]: 2f27632cde
[`imageRouter.postImagesLoad`]: 7b9d2ef6e5/api/server/router/image/image_routes.go (L248-L255)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
For methods using the decodeWithRaw utility, we were handling closing
of the body twice. The ensureReaderClosed utility also drains the
response to let the transport reuse the connnection. Let's use that
utility in decodeWithRaw as well.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These fields store the raw JSON data that we received, and should
never container bytes that are non-JSON (as we'd error out when
failing to unmarshal).
Change the type to a json.RawMessage, which:
- Is more explicit on intent
- Can still be used as a regular []byte in all cases
And, while it's not expected to be marshaled to JSON, doing so will also
print the output in a readable format instead of base64 encoding;
package main
import (
"encoding/json"
"fmt"
)
func main() {
foo := struct {
Bytes []byte
Raw json.RawMessage
}{
Bytes: []byte(`{"hello": "world"}`),
Raw: json.RawMessage(`{"hello": "world"}`),
}
out, _ := json.MarshalIndent(foo, "", " ")
fmt.Println(string(out))
}
Will print:
{
"Bytes": "eyJoZWxsbyI6ICJ3b3JsZCJ9",
"Raw": {
"hello": "world"
}
}
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `ExecInspectResult` type was embedding `ExecInspect`, which is also
defined by the client, so there's no need to abstract it.
While updating, also;
- Rename `ExecID` to `ID`, to match the field-name returned by the API.
- Rename `Pid` to `PID`, to be in the right casing.
- Remove `json` labels, as option-types are not (un)marshaled to JSON.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This panicked when creating a stub; we need to look for better ways to
allow stubbing these (perhaps we need to expose the rc / body)?
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
