Architecture
Last updated
Was this helpful?
Last updated
Was this helpful?
The design mostly follows what's illustrated below. Below is a simplified runtime view of invoking cedana dump runc ...
:
The subcommand cedana dump runc ...
is only available if the runc plugin is exporting the DumpCmd
symbol (check plugins/runc/main.go
). The runc plugin only sets the specific flags it needs (such as --id
, --root
), while the parent cmd handles all the common flags, and sending the request to the daemon.
The daemon receives the request, and runs it through a list of adapters, before finally sending it to CRIU. If the request's type
is runc
, it will use the DumpMiddleware
exported by the runc plugin and plug it in the adapter chain. See internal/server/dump.go
:
This way, the runc plugin only implements the specifics of the runc runtime, while the daemon handles the common logic, and invoking CRIU.
The same pattern is followed for dump
, restore
, run
, and manage
.
Symbols that can be exported by a plugin are well-typed and are defined in pkg/features/supported.go
. A feature
implements a convenient method called IfAvailable(do func(), filter ...string)
, which is the only method you will ever need to access a feature exported by a plugin. An example usage:
A useful helper command is cedana features
(alias of cedana plugin features
), which lists all the features supported by all the plugins. This is useful for debugging, when implementing a new feature, or when you want to know what a plugin supports. Use the --errors
flag to also output all errors encountered while loading the plugins.
See feature matrix for more info.