daemon versions before v18.09 (API v1.39) returned a magic `<unknown>` value
for the `KernelVersion` and `OperatingSystem` if these values were not set.
Commit e6e8ab50fa removed this magic values,
but kept a fallback for old versions of the CLI that expected this value to
be pre-formatted this way. Given that this change was over 7 Years ago, and
never was a strict contract of the API, we can remove this fallback. Current
versions of the CLI properly handle presentation, so this would only impact
EOL versions of the CLI.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
As the Engine API requests may be directed at a non-leader Swarm
manager, the information needs to be tunneled through the Swarm API.
Signed-off-by: Cory Snider <csnider@mirantis.com>
All the fields in DefaultNetworkSettings were deprecated in Engine v1.9
and scheduled for removal in v17.12. However, they're still return in
all supported API versions.
As we still need to keep backward compatibility for older API versions,
this change leverages the newly added 'compat' package to return these
fields despite being removed from the Go struct.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Don't include the deprecated `status`, `id`, and `from` fields in event
responses.
These fields were deprecated in [moby@72f188] (docker v1.10, API v1.22),
but the daemon still included them in the response.
Unfortunately, the Docker CLI (and compose indirectly), continued using
these fields up until v25.0.0, and panic if the fields are omitted, or
left empty (due to a bug), see: https://github.com/moby/moby/pull/50832#issuecomment-3276600925
so we need to continue producing these fields on API < v1.52.
[moby@72f188]: 72f1881df1
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On API v1.52 and newer, the GET /networks/{id} endpoint returns
statistics about the IPAM state for the subnets assigned to the network.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Move the option-types to the client and in some cases create a
copy for the backend. These types are used to construct query-
args, and not marshaled to JSON, and can be replaced with functional
options in the client.
The CreateOptions type was used both as options-struct for the client,
and as struct to marshal/unmarshal the request. For this type, a copy
is created in the Client and a new `checkpoint.CreateRequest` is added
in the API.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Move the option-types to the client and in some cases create a
copy for the backend. These types are used to construct query-
args, and not marshaled to JSON, and can be replaced with functional
options in the client.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While the network Summary and Inspect types have been aliases in Go's
type system, in practice there is a difference: the Containers and
Services fields are only populated when inspecting a network. Split out
the common fields into a base network.Network struct which is embedded
in the network.Summary and network.Inspect types.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Filter-term validation does not belong in the API module. Clients should
not be making any assumptions about which terms the daemon understands.
Users should not need to upgrade their clients to use filter terms
introduced in a newer daemon. Move the network filter validation from
the api module into the daemon.
Split network.NewFilter into network.NewListFilter and
network.NewPruneFilter constructors which validate the filter terms,
enforcing the invariant that any network.Filter is a well-formed filter
for networks.
The network route handlers have been leveraging a hidden 'idOrName'
filter term that is not listed in the set of accepted filters and
therefore not accepted in API client requests. And it's a good thing
that it was never part of the API: it is completely broken and not fit
for purpose! When a filter contains an idOrName term, the term values
are ignored and instead the filter tests whether either the 'id' or
'name' terms match the Name of the network. Unless the filter contains
both 'id' and 'name' terms, the match will evaluate to true for all
networks! None of the daemon-internal users of 'idOrName' set either
of those terms, therefore it has the same effect as if the filter did
not contain the 'idOrName' term in the first place.
Filtering networks by id-or-name is a quirky thing that the daemon needs
to do to uphold its end of the Engine API contract, not something that
would be of use to clients. Fixing up the idOrName filter would
necessitate adding it to the list of accepted terms so the filter passes
validaton, which would have the side effect of also making the filter
available to API clients. Instead, add an exported field to the Filter
struct so that daemon code can opt into the internal-only behaviour of
having the 'id' term match on either the network Name or ID.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Construct a network.Filter from the filters.Args only once per API
request so we don't waste cycles re-validating an already validated
filter. Since (*Daemon).NetworksPrune is implemented in terms of
(Cluster).GetNetworks, that method now accepts a network.Filter instead
of a filter.Args. Change the signature of (*Daemon).GetNetworks for
consistency as both of the GetNetworks methods are used by network API
route handlers.
Signed-off-by: Cory Snider <csnider@mirantis.com>
These consts are no longer used, and separate consts were added in both
the client and daemon packages;
- client: 41da5700a4
- daemon: a632b8495b
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This change moves the `system.SecurityOpt` type and `system.DecodeSecurityOptions` function to the client and adds a set of unit tests to capture current implementation. This change also create a set of daemon backend copies for usage.
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
Commit 0ca7ac325 was merged before a review comment was addressed.
Update the warning message returned by handlePortBindingsBC to handle
the case where multiple empty port bindings slices are sent to the API.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
So far, on ContainerStart, the daemon was silently backfilling empty
PortBindings slices with a PortBinding with unspecified HostIP and
HostPort. This was done by github.com/docker/go-connections/nat.SortPortMap.
This backfilling doesn't make much sense, and we're trying to remove
that package. So, move the backfilling to the API server, keep it for
older API versions, deprecate it for API 1.52, and drop it for API 1.53
and above.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
This change moves the logic that is used to marshal the legacy extra fields for `registry.ServiceConfig` type to the daemon backend.
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
