Skip to content

[Question]: Intended Runtime Options Override Mechanism #2014

Description

@ndbaker1

Question:

what is the intended mechanism today for setting containerd runtime overrides when using the tookit installer?

asking since there does still appear to be a --runtime-config-override flag, but seems to be an unintended artifact of #722 which followed its removal in a previous PR #643 (comment) with rationale that it was unnecessary complexity.

&cli.StringFlag{
Name: "runtime-config-override",
Destination: &opts.runtimeConfigOverrideJSON,
Usage: "specify additional runtime options as a JSON string. The paths are relative to the runtime config.",
Value: "{}",
Sources: cli.EnvVars("RUNTIME_CONFIG_OVERRIDE", "CONTAINERD_RUNTIME_CONFIG_OVERRIDE"),
},

the "inheritance" mechanism which reads from the default or fallback runtime block works sufficiently well, but is tied closer to node infra/provisioning, which doesn't feel ideal for dynamic installations.

hoping to either re-introduce the --runtime-config-override feature or note down a recommended stance on how this should be done (and remove the dead code). maybe externally-managed containerd drop-in configs are the right way to go but then thats implicitly tied to the chosen NVIDIA_RUNTIME_NAME and whatnot.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionCategorizes issue or PR as a support question.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions