You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My understanding is that we can use the update manager to install/update arbitrary types of artifacts on the device.
In particular, the container update agent supports running OCI container workloads. The agent's desired state spec seems to support setting environment variables for the containers and also seems to allow for folders/files of the host file system to be mounted into a container's file system. That is all fine and appreciated :-)
Many of the container images that we are using need to load configuration information and/or secrets like passwords or tokens from a file whose path in the container's local file system is often specified by means of an environment variable. So, the immediate question that arises is: how do we transfer/install the configuration/secret file to the device's host file system so that it can then be mounted into the container?
I guess what I am looking for is something like the ConfigMap/Secret construct supported by k8s. I could imagine supporting something similar by means of a dedicated update agent that can create such resources in the device's local file system using a logical name based on the descriptor passed in via the update manager. The mechanism could indeed be quite similar to k8s functionality, e.g. it could support supplying the config/secret content inline in the (JSON) descriptor.
However, this would then also require the container update agent to support mounting of such resources by means of a logical config/secret name instead of an absolute file system path.
The text was updated successfully, but these errors were encountered:
Hi @sophokles73,
We will make an analysis of the feature request and eventually consider it for the Eclipse Kanto M5 release, which is planned for end of November 2023.
Maybe in this context it would also make sense to think about using Podman instead of containerd for running containers, because it already comes with support for ConfigMaps and Secrets out-of-the-box if I am not mistaken. And, as a free bonus, it also supports specifying workloads using standard k8s manifest files ...
My understanding is that we can use the update manager to install/update arbitrary types of artifacts on the device.
In particular, the container update agent supports running OCI container workloads. The agent's desired state spec seems to support setting environment variables for the containers and also seems to allow for folders/files of the host file system to be mounted into a container's file system. That is all fine and appreciated :-)
Many of the container images that we are using need to load configuration information and/or secrets like passwords or tokens from a file whose path in the container's local file system is often specified by means of an environment variable. So, the immediate question that arises is: how do we transfer/install the configuration/secret file to the device's host file system so that it can then be mounted into the container?
I guess what I am looking for is something like the ConfigMap/Secret construct supported by k8s. I could imagine supporting something similar by means of a dedicated update agent that can create such resources in the device's local file system using a logical name based on the descriptor passed in via the update manager. The mechanism could indeed be quite similar to k8s functionality, e.g. it could support supplying the config/secret content inline in the (JSON) descriptor.
However, this would then also require the container update agent to support mounting of such resources by means of a logical config/secret name instead of an absolute file system path.
The text was updated successfully, but these errors were encountered: