This includes the changes from c13266d2c0
in the versioned swagger, as those changes were made after the
v1.52 versioned document was created.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Outline the purpose of the Stdin and Systemerr streams and how
they're used.
- Update docs for StdCopy function
- Touch-up error for unknown stream types
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
iota can be convenient for internal use for cases where the value
doesn't matter. It can be a footgun when using it to define public
values; it's easy to accidentally change values (e.g. by re-ordering
or adding a value), which may go undetected within our code because
both producer and consumer would be updated.
This patch updates these consts to have a concrete value, because it's
part of the API contract and must not be changed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The wire type of Plugin.Config.Interface.Types is an array of strings,
not of objects with three properties. We just so happen to have a Go
struct type to represent a plugin-interface-type value in memory with
all the fields parsed out for convenience, but that is not part of the
REST API contract documented by the Swager spec.U pdate the Swagger spec
to correctly document that the Types property is an array of strings in
the API, while still generating Go definitions that unmarshal into the
convenient struct type.
Move the definition and marshal/unmarshal methods for
PluginInterfaceType into a more appropriate location than api/types.
Rename the type to one that does not stutter or overload already
heavily overloaded terminology.
Modernize the parser and use property-based testing to assert that it
behaves the same as the old parser for all well-formed inputs.
Signed-off-by: Cory Snider <csnider@mirantis.com>
This reverts commit 3a447bc079.
Some daemon versions don't handle empty values well, which resulted in
an io.EOF error when sending an empty X-Registry-Auth during decoding
or unmarshaling.
We should investigate what code-paths are hit to trigger this, but
in the meantime, let's revert this patch.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This allows us to update code to not be attached to go-connections
directly (in future we may be able to move the types to be concrete
types).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The API still returns it for backward-compatibility (but probably
shouldn't), but we should no longer print it. This removes the
use of these fields for printing, but keeps them for streamformatter
to use.
- ErrorMessage was deprecated in 3043c26419
- ProgressMessage was deprecated in 597e0e69b4
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Move the type to the API, but embed it, so that we keep the
methods on the struct in this package.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's only used by the client to support API versions older than v1.22.
Make it an internal utility that doesn't depend on internal fields of
`filter.Args`.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These types used to be internal to the container package, but were
moved to the API in 100102108b.
However, the `StateStatus` type is only used internally; it's used
as an intermediate type because [`container.State`] contains a sync.Mutex
field which would make copying it unsafe (see [moby@2998945]).
This moves the type and re-introduces an internal type
in the original location, effectively reverting
100102108b
[`container.State`]: 19e79906cb/container/state.go (L15-L23)
[moby@2998945]: 2998945a54
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
While it is imported by both the client and the daemon, values of the
PluginCreateOptions struct are not marshaled or unmarshaled. The only
field is mapped to and from an HTTP query parameter. Furthermore, this
options type is the odd one out: the daemon uses types in
api/types/backend to pass options around for the other plugin lifecycle
operations. Move the PluginCreateOptions type into client, and define a
new PluginCreateConfig struct in api/types/backend for the daemon to use
alongside PluginRmConfig, PluginEnableConfig and PluginDisableConfig.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
