Closed sophokles73 closed 9 months ago
@sophokles73 I propose an initial setup like this.
A simple iteractive (cli) selector that reads all desired state json files (with some added metadata such as name/description) and allows the user to select which blueprint to deploy over MQTT using the arrows keys/enter.
I have implemented this as a POC (check the example_blueprints diretory and the readme): https://github.com/SoftwareDefinedVehicle/leda-utils-fork/tree/feature/blueprints-selector/src/rust/blueprint-selector
If you like the idea of this tool, it could be later expanded to support fetching the .blueprint.json files directly from a git repo instead of reading them from a local folder.
Tested on a Leda QEMUx86 (with UM+CUA available) image with port 1883 forwarded to the host and the ergonomics of this setup are quite nice IMO.
@vasilvas99 This looks nice :+1:
We are currently publishing the desired state to the MQTT broker running in Leda using mosquitto_pub
. But your CLI looks much more user-friendly and has the advantage of not requiring an MQTT client to be installed on the host system.
If you like the idea of this tool, it could be later expanded to support fetching the .blueprint.json files directly from a git repo instead of reading them from a local folder.
That would be cool indeed :-)
The Kanto Container Update Agent has been included in the Leda 0.1.0-M3 milestone. Closed via 52e1a621558852ffd5255608c7c55b23b6f4add1
The Leda setup guide is currently based on manually copying files to the Leda instance for deploying the components.
Once Leda has included Kanto's Update Manager into a release, we should try to use a desired state specification that we feed into the Update Manager to deploy the application components.