Hi @egernst. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Looks like the branch you started from is missing some recent commits from main that fix a CI issue on Vagrant. I know your PR content has nothing to do with any of those test flows, but will be easier to get "green" CI if you rebase on main.

Thanks Phil (and Sam). Rebased accordingly.

@samuelkarp Can you take a look?

I tried running this, but I'm getting a bunch of errors like this:

ERRO[0006] running container 0-13130                     error="rpc error: code = Unknown desc = failed to get sandbox runtime: no runtime for \"io.containerd.runc.v2\" is configured"
E0610 13:08:02.923645  254737 remote_runtime.go:135] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = failed to get sandbox runtime: no runtime for "io.containerd.runc.v2" is configured

Here's how I invoked it:

$ sudo bin/containerd-stress --cri

Meanwhile, the io.containerd.runc.v2 runtime appears to work when I use ctr:

$ sudo ctr run --runtime io.containerd.runc.v2 --rm docker.io/library/debian:latest test cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

@samuelkarp thanks for giving it a try. crictl/CRI doesn't use the containerd fully qualified runtime name. Instead, it just uses the handler name. For runc, it'd be runc. In Kata case, in my testing I just use kata.

Example:

sudo ./containerd-stress --duration 24h --runtime runc --cri  --concurrent 30

I updated the usage of --cri in order to help clarify this change in expectations:

...
   --cri                         utilize CRI to create pods for the stress test. This requires a runtime that matches CRI runtime handler. Example: --runtime runc
...

crictl/CRI doesn't use the containerd fully qualified runtime name.

I didn't specify a runtime name, that was the default when running containerd-stress with just the --cri option specified. Can you make it so that the default behavior works (i.e., containerd-stress itself knows to use "runc" instead of "io.containerd.runc.v2" when constructing requests) or document that --runtime must also be specified when using --cri?

With that said, when I run the command you provided I get further errors as follows:

ERRO[0001] running container 24-20                       error="rpc error: code = Unknown desc = failed to setup network for sandbox \"cb9858cad06ba2349ba0e335074ba6ab1d0c976848c808d19b402f4e5609bccc\": cni plugin not initialized"

Can you document the requirements for running containerd-stress in this new mode? I assume it'd be something like:

• enable the CRI plugin
• install CNI plugins, configure containerd to use them
• specify --runtime runc

I updated the --cri usage to provide more details on expectations of --runtime flag -- does that meet your needs?

I think we'll probably want to introduce a README for containerd-stress if we want to augment and have more details around usage, expectations? WDYT?

I updated the --cri usage to provide more details on expectations of --runtime flag -- does that meet your needs?

I don't see a new change yet (maybe it didn't get pushed?), but that would probably work.

Goodness gracious, my fault. actually pushed now. Thanks.

Hey Mike -- I did consider this initially. I want the same ux as existing containerd-stress, and frankly, the containerd-stress codebase was much easier to work with. We already have a (nice) package for interacting with CRI in containerd, and we are exercising the CRI handling which is implemented within containerd, so I figured it is pretty reasonable to include here.