Kernel resource management enhancement.

[jglogan]

We have a several loose ends around kernel UX and multiple open and closed issues:

UX-related:

• [Request]: Clearer error message when no kernel present #1328
• [Bug]: Unable to update kernel unless existing one is wiped #905

Related to distributing a custom kernel (which is not practical for us today):

• [Request]: Use containerization kernel as the default kernel #1144
• [Request]: Download a linux kernel with kvm support by default #1222
• [Request]: CONFIG_TUN=y would be nice #1182 (resolved because Kata enabled TUN)
• [Bug]: nf_tables not initialized - Docker daemon fails inside containers #1002 (resolved because Kata enabled NF_TABLES)
• [Request]: Support /dev/ppp device (PPP/L2TP functionality) in Apple Container kernel #866

I'm starting up this discussion so we can put together a better design and UX for our kernel related features. Right now kernels are a second class citizen and the way they work in system properties (macOS UserDefaults which will likely go away), container system start, and the --kernel option of create and run is a bit disjointed.

Here are some possible user stories. Let me know what you think about these and any other points of design.

• As a container user, I can run container system start for a new install or upgrade, and if the current default kernel is not present on my system, the tool shall download the kernel, and update the default container resource, so that my containers use the kernel that was tested with the application release.
• As a container user, I can run a kernel create subcommand that accepts a remote archive URL or local archive pathname, and a member pathname for the kernel file, downloads the archive if necessary, extracts the kernel file and creates a managed kernel resource with a specified ID, so that I can easily use the kernel with containers I run.
• As a container user, I can run a kernel create subcommand that accepts a remote kernel file URL or local kernel file pathname, downloads the kernel file if necessary, and creates a managed kernel resource with a specified ID, so that I can easily use the kernel with containers I run.
• As a container user, I can run a kernel delete subcommand that deletes kernel resources for the specified IDs, so that I can recover disk capacity.
• As a container user, I can run a kernel list subcommand that displays kernel resources, so that I can see what kernels are available on my system.
• As a container user, I can run a kernel inspect subcommand that displays the attributes of the specified kernel as JSON, so that I can see all details of a kernel and use tools that interact with container resources.
• As a container user, I can use the --kernel option of the container create/run subcommands with a kernel ID, so that I can launch containers using convenient kernel names.
• As a container user, I can use the --kernel option with an absolute or relative pathname to a container file, so that I can quickly try out a kernel without installing it as a resource.
• As a container user, I can amend the default kernel using a personal configuration file, so that I can use an alternate kernel for all of my containers.
• As a container user, I can amend the default kernel using an environment variable, so that I can use an alternate kernel for all containers in a shell session.
• As a container user, I can run a kernel build subcommand that accepts a kernel source URL and a kernel configuration file, builds a kernel in a container, copies the result into my current directory, so that I can create a container resource and run containers with it.

[katiewasnothere]

Is the kernel config in https://github.com/apple/containerization/blob/main/kernel/config-arm64 the minimal set of configs necessary to run containers?

[jglogan]

Not AFAIK. There are things enabled there that aren't in the Kata kernel we use as a default.