KAD: Potential offline usecase and pre-integration into existing automotive toolchains

[mikehaller]

Another team asked whether Leda would be able to import container archives from an USB stick, or whether container archives (and maybe deployment manifests) could be packaged as Conan packages for installation. I think it's two separate use cases, but i'm not quiet sure yet:

• Pre-installation of containerized applications using an existing automotive build toolchain. (e.g. by Conan packages).
• Offline-installation of containerized applications via an USB-Stick

As Leda team, we've been discussing whether kanto-auto-deployer would be the right place to implement/support these use cases. We consider KAD to be a convenience-tool for Leda quickstart image users, filling in the "gaps" in the SDV deployment concepts until they have been solved properly.

We have a tendency to say, let's support these use cases, but would like to get feedback from the community as well:

• KAD to monitor USB devices (or arbitrary dynamic mount points) for new container images (archives). This may bloat the scope of KAD, increase the binary size and makes it harder to maintain. It violates a bit the "one tool for one job" philosophy.
• Alternative to use a local container registry, acting as a proxy, so that container runtime or other tool like KAD doesn't need know about whether the container archives originate from. This is a level of indirection for the users and may be confusing at first.

Does anybody have such or similar use cases, please leave a comment!

[d-s-e]

Pre-installation of containerized applications should only be done with the build system (Yocto) - all the necessary recipes are already available. Running arbitrary images that have been copied to the system is also currently possible using low-level tools like ctr, but that is not very convenient.

IMHO the best solution would be to use a local registry acting as a proxy/pull through cache that will be pulled by KAD. This will also simplify container development, because then it's possible to avoid the unnecessary round trip of pushing an image several times to another registry somewhere not in the local network. Also the deployment is handled by an already working system.

The workflow for container images, no matter if they are built with Conan, Yocto or something else, then could be:

1. Copy the container archive from the USB stick or via ssh to the local registry.
2. Copy the manifest to KAD's manifest folder.
3. KAD recognizes the change, pulls the image from the local registry and starts the container.

Looks fairly simple to me.

To go one step further: Steps 1 and 2 could be made easier by integrating them into some kind of TUI.

I don't think, that any arbitrary devices or mount points should be monitored by KAD other than the manifest folder; "one tool for one job", as you say.

Another issue: Should USB drives be mounted automatically anyway?

[vasilvas99]

I agree with @d-s-e more or less.

From previous experience, however, I can say that what Mike is describing (i.e. people wanting to update with a USB stick) is not that uncommon in production for airgapped embedded systems. Even RAUC supports that mode of update.

My general concern is that this leads to "the user plugs an arbitrary USB stick which leads to the execution of arbitrary code". If we are to do something like this, it should be a separate service that does signed image verification with a pre-baked private key (RAUC-style) and injects the container image in the kanto namespace, while leaving KAD only to deal with deploying manifests.

[vasilvas99]

@mikehaller @d-s-e What about evaluating Eclipse Hawkbit (https://eclipse.dev/hawkbit/)? It's specification is basically a tar + desired state and it can fetch through various means + kanto already works with it?

Credit for the idea: Kristiyan Gostev (Eclipse Kanto project lead)

[d-s-e]

It looks like we already had Hawkbit on Leda in the past, though I don't know why it has been removed.

Rauc alone can't handle this? What are the benefits of using Hawkbit? It seems, that it will add some additional complexity ...