Make Ignite run out-of-the-box with containerd and bridge cni

[chanwit]

This issue discusses and finds a way to implement better UX when using ignite with containerd.

• ignited should ship with its own containerd, shim and runc. We'll choose a specific version
• ignited should start the embedded containerd
• ignited should ship with at least the bridge, loopback cni and the default config to make network work OOTB.
• provide a setup script like curl -sSL https://get.ignite | sh and everything in place.

With this, we would need to run sudo ignited daemon first. Then we use ignite to interact with it. This shall also move us towards ignite as a client only.

[chanwit]

addressed by #400

[ztmr]

Can we at least make the CNI path configurable in the meantime?

I am trying to run Ignite on NixOS which has CNI package but does not install it in the /opt/cni, so it would be great to be able to pass a CNI directory path to Ignite binaries explicitly, either via command line or env variable. Happy to raise a PR if we agree on the approach...

This would help me package and use Ignite on Nix platform ;-)

[ztmr]

One more thing: ignite is passing the paths to go-cni, so it would be nice if go-cni itself detected some kind of env var with overrides and this way, we would not need to do anything in ignite. However, it is still not nice to have these hardcoded!

[stealthybox]

We've talked before about making CNI configurable in the Ignite Config API object that changes ignite's general behavior.

This would also have a key benefit in allowing a single ignite host to use multiple configurations for multiple different CNI networks on the same machine without relying on a CNI multiplexing solution like Multus:

https://github.com/weaveworks/ignite/issues/315#issuecomment-533047806

I'm +1 on adding this to the Ignite Config.

Seems like you would want both the CNI bin and conf dirs to be configurable at a minimum.

There are also suggested fields for ignite's heuristic/default CNI behavior when there is no config. Maybe those should be in a different struct?

[stealthybox]

CNI confdir config can already be mutated at a host level while VM's (or even more generally, containers) are running. That will affect the way the CNI plugins execute globally on the machine.

With this reasoning, it doesn't really feel any worse to add this at the ignite Config level rather than on the VM spec. Adding this to Config improves the situation, because you can override the Config.

Anybody else have an opinion?

[casibbald]

Sounds great if it can be overridden

On Mon, 5 Apr 2021 at 20:26, leigh capili @.***> wrote:

CNI confdir config can already be mutated at a host level while VM's (or even more generally, containers) are running. That will affect the way the CNI plugins execute globally on the machine.

With this reasoning, it doesn't really feel any worse to add this at the ignite Config level rather than on the VM spec. Adding this to Config improves the situation, because you can override the Config.

Anybody else have an opinion?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/weaveworks/ignite/issues/399#issuecomment-813519196, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA6C36W4YGIKAI2YJCQ5MDTHHXEDANCNFSM4IT6CGPA .