It has no external users, and this package still has too many different
responsibilities, some of which may be available elsewhere, so moving it
internal so that we can decide to dismantle it further.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
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 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>
These functions were used internally to keep track of whether containerd
was enabled as runtime on Windows; move it to libcontainerd.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The restartmanager is only used internally by the daemon, and has no external
users. Move it to the daemon/internal package.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>