Begin adding support for multiple OCI runtimes #3378
Conversation
Allow Podman containers to request to use a specific OCI runtime if multiple runtimes are configured. This is the first step to properly supporting containers in a multi-runtime environment. The biggest changes are that all OCI runtimes are now initialized when Podman creates its runtime, and containers now use the runtime requested in their configuration (instead of always the default runtime). Signed-off-by: Matthew Heon <matthew.heon@pm.me>
We may want to ship configurations including more than one runtime configuration - for example, crun and runc and kata, all configured. However, we don't want to make these extra runtimes hard requirements, so let's not fatally error when we can't find their executables. Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mheon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
approved
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
Step 2 from here is add support for probing runtime features on those runtimes, so I can be able to detect whether a runtime supports something (for example, opencontainers/runc#2062 - which we need to prevent systemd from closing down our scopes immediately on shutdown request - but probably isn't as relevant to, say, kata). |
|
The problem in CI is the |
| ctr.ociRuntime = s.runtime.defaultOCIRuntime | ||
| } else { | ||
| ociRuntime, ok := s.runtime.ociRuntimes[ctr.config.OCIRuntime] | ||
| if !ok { |
There was a problem hiding this comment.
we support specifying the runtime by an absolute path, we needed it to avoid a breaking change. When the runtime starts with / we use directly the specified path without any lookup. Should we take care of this case here and skip the error when ctr.config.OCIRuntime[0] == '/' ?
There was a problem hiding this comment.
Actually, didn't quite catch the case where older containers might be stored with paths starting with a /... For that, I think we can try grabbing the basename and looking up the runtime by that.
This is done by the --runtime flag, and as such, by all our CI. Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Try and locate the right runtime by using the basename of the path. Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
Do we not have runc in the test images? What's going on here? |
|
Oh wait, I got it. Working on it now. |
Use name of the default runtime, instead of the OCIRuntime config option, which may include a full path. Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
Prow appears to be blowing up. Infra problems? |
|
/retest |
|
Tests going green, ready for review |
|
LGTM |
|
tested locally /lgtm |
github-actions
bot
added
the
locked - please file new issue/PR
Containers already remember the runtime they were created with in their configs. Now, let's allow them to request that runtime on subsequent runs of Podman. This greatly improves support for running multiple OCI runtimes at once - containers started on
crunorkatawill continue to use those runtimes even if the default runtime swaps torunc, for example.