From 2a4d31abd7611d960bad751625a3fe557718b0b7 Mon Sep 17 00:00:00 2001 From: Kai Hudalla Date: Mon, 20 Nov 2023 09:08:24 +0100 Subject: [PATCH] Use Kanto Update Manager to install in-vehicle components Added a "desired state" document for the containers need to run in the vehicle. Also adapted the Setup guide to use the Update Manager to run the containers. --- leda/{Setup.md => README.md} | 64 ++++++++++-------- leda/fms-desired-state.json | 123 +++++++++++++++++++++++++++++++++++ 2 files changed, 160 insertions(+), 27 deletions(-) rename leda/{Setup.md => README.md} (59%) create mode 100644 leda/fms-desired-state.json diff --git a/leda/Setup.md b/leda/README.md similarity index 59% rename from leda/Setup.md rename to leda/README.md index 7f17292..89f8485 100644 --- a/leda/Setup.md +++ b/leda/README.md @@ -21,15 +21,20 @@ SPDX-License-Identifier: Apache-2.0 # Setup with Eclipse Leda -The components of the Fleet Management blueprint fall into two categories: the *KUKSA.val Databroker*, -*CSV Provider* and *FMS Forwarder* components are supposed to run in the vehicle, whereas the remaining -components are supposed to run in a (cloud) back end to which the vehicle is connected via (public internet) -networking infrastructure. +The components of the Fleet Management blueprint fall into two categories: the +*KUKSA.val Databroker*, *CSV Provider* and *FMS Forwarder* components are +supposed to run in the vehicle, whereas the remaining components are supposed +to run in a (cloud) back end to which the vehicle is connected via (public +internet) networking infrastructure. -All of the components can be run on a single Docker host as described in the [top level README](../README.md). However, the following sections describe a more realistic deployment scenario in which -[Eclipse Leda](https://eclipse-leda.github.io/leda/) is used as the vehicle runtime environment. +All of the components can be run on a single Docker host as described in the +[top level README](../README.md). However, the following sections describe a +more realistic deployment scenario in which [Eclipse Leda](https://eclipse-leda.github.io/leda/) +is used as the vehicle runtime environment. -This guide was tested with release v0.1.0-M2 of Eclipse Leda. +This guide was tested with pre-release +[test-0.1.0-M3-rc](https://github.com/SoftwareDefinedVehicle/leda-distro-fork/releases/tag/test-0.1.0-M3-rc) +of Eclipse Leda. # Start Back End Components @@ -42,39 +47,42 @@ docker compose -f fms-blueprint-compose.yaml up influxdb grafana fms-server --de # Start In-Vehicle Coponents -In the setup described here, the containers for the in-vehicle components -are deployed to a Leda instance running on the -same (local) host as the back-end components. -The *FMS Forwarder* running in Leda then connects to the *influxdb* server managed -by Docker Compose. See below for more details on how to deploy the components to different devices. +In the setup described here, the containers for the in-vehicle components are +deployed to a Leda instance running on the same (local) host as the back-end +components. The *FMS Forwarder* running in Leda then connects to the *influxdb* +server managed by Docker Compose. Please refer to [Leda's Getting Started](https://eclipse-leda.github.io/leda/docs/general-usage/) guide for setting up a Leda instance. ## Stop default Containers -Leda comes with a set of default containers (including KUKSA.val Databroker) that are managed using -Eclipse Kanto's *container-manager*. These containers are defined by means of JSON manifest files in -Leda's `/data/var/containers/mainfests` folder. +Leda comes with a set of default containers (including KUKSA.val Databroker) that +are managed using Eclipse Kanto's *container-manager*. These containers are defined +by means of JSON manifest files in Leda's `/data/var/containers/mainfests` folder. -We will stop and disable some of Leda's default containers, make some changes to the configuration of the -Databroker container and also deploy additional containers. +We will stop and disable some of Leda's default containers, make some changes to the +configuration of the Databroker container and also deploy additional containers. ```sh # in Leda instance's /data/var/containers/mainfests folder tar cf manifests.orig.tar * kanto-cm stop --force -n feedercan mv feedercan.json feedercan.json.disabled +kanto-cm stop --force -n feedergps +mv feedergps.json feedergps.json.disabled kanto-cm stop --force -n hvacservice-example mv hvac.json hvac.json.disabled +kanto-cm stop --force -n node-red-example +mv node-red.json node-red.json.disabled kanto-cm stop --force -n seatservice-example mv seatservice.json seatservice.json.disabled ``` ## Deploy in-vehicle Blueprint Components -Some of the Fleet Management blueprint containers require access to configuration files that are not present -in Leda, e.g. the FMS-specific VSS definitions. +Some of the Fleet Management blueprint containers require access to configuration files +that are not present in Leda, e.g. the FMS-specific VSS definitions. Create the folders in Leda from which the containers can mount these files: @@ -102,16 +110,18 @@ scp -P 2222 spec/overlay/vss.json root@127.0.0.1:/data/usr/fms/databroker scp -P 2222 /tmp/influxdb.token root@127.0.0.1:/data/usr/fms/forwarder ``` -Finally, copy the manifest files to Leda, triggering the execution of the in-vehicle containers: +Finally, apply the desired state to the Update Manager running on Leda in order to +trigger execution of the in-vehicle components: ```sh # in this repository's root folder -scp -P 2222 leda/data/var/containers/manifests/*.json root@127.0.0.1:/data/var/containers/manifests +mosquitto_pub -h localhost -f leda/fms-desired-state.json -t vehicleupdate/desiredstate ``` -If you want to deploy the in-vehicle and the back-end components to different devices, -for example, a RaspberryPi 4 and a developer machine, -you need to replace the network address `127.0.0.1` in the scp-commands -with the respective IP address of the in-vehicle device. You also need to -adapt the IP address of the influx database in the container manifest for -the *FMS-Forwarder* (`config.env.INFLUXDB_URI` in `data/var/containers/manifests/fms-forwarder.json`) +# Run in-vehicle Components on a separate Node + +If you want to run the in-vehicle and the back-end components on different devices, +e.g. a RaspberryPi 4 and a developer machine, you need to replace the network address +`127.0.0.1` in the `scp` commands with the respective IP address of the in-vehicle device. +You also need to adapt the IP address of the influx database in the container manifest +for the *FMS-Forwarder* (`config.env.INFLUXDB_URI` in `data/var/containers/manifests/fms-forwarder.json`). diff --git a/leda/fms-desired-state.json b/leda/fms-desired-state.json new file mode 100644 index 0000000..ca8e8c3 --- /dev/null +++ b/leda/fms-desired-state.json @@ -0,0 +1,123 @@ +{ + "activityId": "install-FMS-components", + "payload": { + "domains": [ + { + "id": "containers", + "config": [], + "components": [ + { + "id": "databroker", + "version": "0.4.1", + "config": [ + { + "key": "image", + "value": "ghcr.io/eclipse/kuksa.val/databroker:0.4.1" + }, + { + "key": "env", + "value": "RUST_LOG=info" + }, + { + "key": "env", + "value": "KUKSA_DATA_BROKER_METADATA_FILE=/etc/databroker/vss.json" + }, + { + "key": "port", + "value": "127.0.0.1:30555:55555" + }, + { + "key": "mount", + "value": "/data/usr/fms/databroker:/etc/databroker:rprivate" + }, + { + "key": "logMaxSize", + "value": "1M" + } + ] + }, + { + "id": "csv-provider", + "version": "0.4", + "config": [ + { + "key": "image", + "value": "ghcr.io/eclipse/kuksa.val.feeders/csv-provider:0.4" + }, + { + "key": "env", + "value": "PROVIDER_SIGNALS_FILE=/tmp/fms/csv/signalsFmsRecording.csv" + }, + { + "key": "env", + "value": "PROVIDER_INFINITE=1" + }, + { + "key": "env", + "value": "KUKSA_DATA_BROKER_ADDR=databroker" + }, + { + "key": "env", + "value": "PROVIDER_LOG_LEVEL=INFO" + }, + { + "key": "mount", + "value": "/data/usr/fms/csv:/tmp/fms/csv:rprivate" + }, + { + "key": "host", + "value": "databroker:container_databroker-host" + }, + { + "key": "logMaxSize", + "value": "1M" + } + ] + }, + { + "id": "fms-forwarder", + "version": "main", + "config": [ + { + "key": "image", + "value": "ghcr.io/eclipse-sdv-blueprints/fleet-management/fms-forwarder:main" + }, + { + "key": "cmd", + "value": "influx" + }, + { + "key": "env", + "value": "RUST_LOG=info,fms_forwarder=debug" + }, + { + "key": "env", + "value": "KUKSA_DATA_BROKER_URI=http://databroker:55555" + }, + { + "key": "env", + "value": "INFLUXDB_URI=http://10.0.2.2:8086" + }, + { + "key": "env", + "value": "INFLUXDB_TOKEN_FILE=/etc/forwarder/influxdb.token" + }, + { + "key": "mount", + "value": "/data/usr/fms/forwarder:/etc/forwarder:rprivate" + }, + { + "key": "host", + "value": "databroker:container_databroker-host" + }, + { + "key": "logMaxSize", + "value": "1M" + } + ] + } + ] + } + ] + } +}