This package is used internally by the daemon, and was only used out
side of the daemon by pkg/plugins (for which we still need to look
where it should be kept).
Making it internal because it's trivial to implement if needed by
anyone. The only reason it's a package is to keep it central, and
to make it easier to discover where we have rootlesskit-specific
codepaths in our codebase.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This package is used by the daemon to produce a stack-dump, It has no
external consumers, so we can move it to daemon/internal.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The runconfig package is used by the "container" router to unmarshal, normalize,
and validate a container.CreateRequest. The router converts the result to a
backend.ContainerCreateConfig to be passed on to the backend (daemon).
This package could possibly be part of the router itself, or moved to an
internal package in the server, but we don't have an internal package
there yet.
Put it in daemon/internal for now, which still leaves our options open.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Now that we no longer need the ContainerDecoder interface, we can
simplify this to just a function; effectively the ContainerDecoder
had three tasks;
- decode a container.CreateRequest
- validate the hostConfig
- split the container.CreateRequest to Config, HostConfig, and NetworkingConfig
Rewrite this to a DecodeCreateRequest function that returns
a DecodeCreateRequest.
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>
These errors were not used as sentinel error, and used as any other
"invalid parameter" / "invalid argument" error, so remove them, and
just produce errors where used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Since 28.0.0, an iptables rule related to SCTP has only been
included if escape hatch variable DOCKER_IPTABLES_SCTP_CHECKSUM=1
Nobody's reported that the escape hatch was needed, and the rule
it guards doesn't make sense. So, remove.
Signed-off-by: Rob Murray <rob.murray@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>
The postCommit used the container-decoder from runconfig to unmarshal
the body. However, this function was written to decode a container
CreateRequest. Commit only accepts a container Config, so we can
just unmarshal to that type.
A local `commitRequest` type was added because the client posts a bare
`*container.Config` but it may be empty / nil (see [Client.ContainerCommit]
and [container.CommitOptions]), in which case it must be ignored, and no
overrides to be applied.
[Client.ContainerCommit]: c4afa77157/client/container_commit.go (L52)
[container.CommitOptions]: c4afa77157/api/types/container/options.go (L30)
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>
The stringid package is used in many places; while it's trivial
to implement a similar utility, let's just provide it as a utility
package in the client, removing the daemon-specific logic.
For integration tests, I opted to use the implementation in the
client, as those should not ideally not make assumptions about
the daemon implementation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- refactor programIngressPorts to use Rule.Insert/Append/Delete for improved rule management
- split programIngress() and dependent functions on Add and Del functions
Signed-off-by: Andrey Epifanov <aepifanov@mirantis.com>
