This change moves the api/types/versions package out into client and daemon versions.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
The `VirtualSize` field became redundant with the introduction of content-
addressable images in docker v1.10 (4352da7803),
after which the field was identical to the `Size` field. The field was marked
to be deprecated, which happened in 1261fe69a3
(API v1.43) and removed in API v1.44 (913b0f51ca).
Now that we stop supporting API versions older than v1.44, we can drop this
field; it's a minor breakage of old API versions, but the same information
is available in the "Size" field.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The BuildCache.Parent field was removed in API v1.42 in [moby@e0db820].
While we had to keep the Go struct field around to backfill the field for
older API versions, it's no longer part of API v1.42 and up (using the
"omitempty" is just an implementation detail).
Older clients unconditionally use the `Parents` field if set, and usage
of this field is very limited, so let's remove the field without back-
filling, and have clients use the replacement field;
https://github.com/docker/cli/blob/v28.5.1/cli/command/formatter/buildcache.go
[moby@e0db820]: e0db8207f3
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `DiskUsage.BuilderSize` field was added as part of the, then experimental,
BuildKit builder in [moby@5c3d2d5] (API v1.31). It was deprecated in API v1.32
(through [moby@b225258]) but that change still returned the field. Commit
[moby@31348af] removed it in API v1.42. This field was never documented,
and part of an experimental feature, so we can remove it altogether.
[moby@5c3d2d5]: 5c3d2d552b
[moby@b225258]: b225258496
[moby@31348af]: 31348afa19
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Most of the code in the filters package relates to the unmarshaling,
validation and application of filters from client requests. None of this
is necessary or particularly useful for Go SDK users. Move the full-fat
filters package into daemon/internal and switch all the daemon code to
import that package so we are free to iterate upon the code without
worrying about source-code interface compatibility.
Signed-off-by: Cory Snider <csnider@mirantis.com>
This field was deprecated API v1.48 in [moby@ff191c5], and removed in
API v1.49 in [moby@564abf9].
This patch:
- Removes the field from the API Go types.
- Reimplements the `/info` endpoint with the `compat` package to replace
the local `infoResponse` implementation.
- Removes the `ServiceConfig.ExtraFields` field in api/types/registry
introduced in [moby@7d9c50d] to backfill the `AllowNondistributableArtifactsCIDRs`
and `AllowNondistributableArtifactsHostnames` fields for API < v1.47.
We should also consider deprecating the `ContainerdCommit`, `RuncCommit`
and `InitCommit` fields on the `/info` response (as we also include this
information as part of the components returned in `/version`), but those
can still be useful currently for situations where a user only provides
`docker info` output.
[moby@ff191c5]: ff191c58f7
[moby@564abf9]: 564abf9157
[moby@7d9c50d]: 7d9c50db2b
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
kernel-memory limits are not supported in cgroups v2, and were obsoleted in
[kernel v5.4], producing a `ENOTSUP` in kernel v5.16. Support for this option
was removed in runc and other runtimes, as various LTS kernels contained a
broken implementation, resulting in unpredictable behavior.
We deprecated this option in [moby@b8ca7de], producing a warning when used,
and actively ignore the option since [moby@0798f5f].
Given that setting this option had no effect in most situations, we should
just remove this option instead of continuing to handle it with the expectation
that a runtime may still support it.
Note that we still support RHEL 8 (kernel 4.18) and RHEL 9 (kernel 5.14). We
no longer build packages for Ubuntu 20.04 (kernel 5.4) and Debian Bullseye 11
(kernel 5.10), which still have an LTS / ESM programme, but for those it would
only impact situations where a runtime is used that still supports it, and
an old API version was used.
[kernel v5.4]: https://github.com/torvalds/linux/commit/0158115f702b0ba208ab0
[moby@b8ca7de]: b8ca7de823
[moby@0798f5f]: 0798f5f5cf
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On docker 1.12 (API v1.24) and older, the `SecurityOptions` field of the
`/info` response would only list names of the security options that are
enabled in the daemon. API v1.25 added additional information to this
information. Initially, this included a change to return the information
in structured format (b237189e6c), which
was a backward-incompatible change, so an alternative format was introduced
in 514ca09426 to used a string-slice, but
prefixing options with `name=`, followed by the name of the security-options
and any config options related to it as `key[=<value>]` pairs.
On current API versions:
curl -s --unix-socket /var/run/docker.sock 'http://localhost/v1.51/info' | jq .SecurityOptions
[
"name=seccomp,profile=builtin",
"name=cgroupns"
]
On API version v1.24:
curl -s --unix-socket /var/run/docker.sock 'http://localhost/v1.24/info' | jq .SecurityOptions
[
"seccomp",
"cgroupns"
]
The Docker CLI unconditionally handles either format when presenting the
information; for backward-compatibility, it contains fallback code to handle
cases where no `name=` prefix is present, but this logic is not based on
API version.
Given that any current version of the CLI is handling either format, and
versions of the CLI that did not have this handling are at least 9 Years
old (and long EOL), removing the old format is unlikely to be causing
issues and we can remove this special handling, and return the information
in the current format.
If we consider this information to be relevant for clients, we should
ultimately consider making it available in a more structured format as
was the original intent of b237189e6c.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
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>
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>
The "backend" types in API were designed to decouple the API server
implementation from the daemon, or other parts of the code that
back the API server. This would allow the daemon to evolve (e.g.
functionality moved to different subsystems) without that impacting
the API server's implementation.
Now that the API server is no longer part of the API package (module),
there is no benefit to having it in the API module. The API server
may evolve (and require changes in the backend), which has no direct
relation with the API module (types, responses); the backend definition
is, however, coupled to the API server implementation.
It's worth noting that, while "technically" possible to use the API
server package, and implement an alternative backend implementation,
this has never been a prime objective. The backend definition was
never considered "stable", and we don't expect external users to
(attempt) to use it as such.
This patch moves the backend types to the daemon/server package,
so that they can evolve with the daemon and API server implementation
without that impacting the API module (which we intend to be stable,
following SemVer).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Now that the types for the backend were moved to api/types/backend,
we can move the actual response-type and related options to
api/types/system.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
