Fix Leda deployment #4
Conversation
The GitHub Packages containing the blueprint's images have not been accessible publicly. The packages have been made public and the Leda deployment instructions have been adapted to the latest Leda release. Fixes eclipse-sdv-blueprints#3
| The setup for this FMS scenario assumes a split into components running in the vehicles and components | ||
| running in a (cloud) backend. The following page describes how to configure a Leda instance to become part | ||
| of this FMS setup. More precisely, we deploy the containers for the feedercan, the fms-forwarder, | ||
| and the Kuksa.val databroker with an FMS-specific vehicle model. |
There was a problem hiding this comment.
I would still mention here that the databroker needs to be configured with another vehicle model compared to the default model set in the Eclipse Leda release.
There was a problem hiding this comment.
I will add a comment to the instructions given in the Deploy in-vehicle Components section ...
|
|
||
| ## Run Leda | ||
| The following steps assume a running instance of Eclipse Leda. For more details see the | ||
| [Eclipse Leda Getting Started](https://eclipse-leda.github.io/leda/docs/general-usage/) |
There was a problem hiding this comment.
I would still reference this sub-page of the Eclipse documentation, since it can be helpful for newcomers to Eclipse Leda to have a pointer to the different installation options of Eclipse Leda (QEMU, Pi4, Docker, etc.)
There was a problem hiding this comment.
It is still referenced in the Start In-Vehicle Components section ...
There was a problem hiding this comment.
I See, then I would have mentioned the tested Leda version down there as well. But the current version of mentioning the version here works for me too.
| ## Copy manifests to Leda | ||
| To trigger the execution of the required containers for the FMS setup, copy the manifest files from | ||
| `leda/data/var/containers/manifests` in the host to `/data/var/containers/manifests` in Leda: | ||
| The containers for the back end components are run on the local host using Docker Compose: |
There was a problem hiding this comment.
We could mention the different available profiles here or reference the description of the Compose file here.
There was a problem hiding this comment.
FMPOV this should be covered as part of adding a description (in another PR) of how to set it up using Eclipse Hono. In a cloud based setup I would not suggest to connect the vehicle(s) directly to influxdb ...
There was a problem hiding this comment.
Describing this in another PR sounds good to me, as far as the 'direct' profile is the default.
leda/Setup.md
Outdated
| - `mkdir -p /data/usr/fms/dbc` | ||
| - `mkdir -p /data/usr/fms/databroker` | ||
| The containers for the in-vehicle components are deployed to a Leda instance running on the | ||
| local host. The *FMS Forwarder* running in Leda will then connect to the *influxdb* server running |
There was a problem hiding this comment.
I think it good that we explicitly mention that this guide assumes the in-vehicle (Leda) and the back end side on the same host. What do you think about adding a hint that they could in general run on different hosts (Pi and VM in the Cloud)?
There was a problem hiding this comment.
FMPOV this should be covered as part of adding a description (in another PR) of how to set it up using Eclipse Hono. In a cloud based setup I would not suggest to connect the vehicle(s) directly to influxdb ...
There was a problem hiding this comment.
Ok, this could be part of another PR as well. I would not be that strict about only using Hono in a cloud based setup. If we still talk about an example deployment or have a setup where the "Cloud" runs in the local network, e.g., on developer computer and the in-vehicle stack on a RaspberryPi, going for deploying Hono adds overhead for the computation, deployment of Hono.
To me the hint of running it in a local host, may raise the question for a newcomer what would break if you do not use a localhost setup while technically it is not required (even there might be reasons to go for the Hono based setup).
There was a problem hiding this comment.
Any suggestion as to what wording we should include?
There was a problem hiding this comment.
Yes, I created a PR in #8
|
@eriksven would you mind taking another look? |
|
LGTM and I am ignoring the failed checks since we disabled the container image push in #6 anyway. |
…le/fix_leda_deployment Fix Leda deployment
The GitHub Packages containing the blueprint's images have not
been accessible publicly.
The packages have been made public and the Leda deployment
instructions have been adapted to the latest Leda release.
Fixes #3