Skip to content

Release Testing

Jump to bottom
Erik Jaegervall edited this page May 3, 2024 · 4 revisions

Copied from kuksa.val.feeders, not all parts may be updated!

Release testing is done for components in status Beta/production/stable/mature at https://github.com/eclipse/kuksa.val/wiki/KUKSA.val-Component-Maturity.

Prerequisites

  • Kuksa-client PyPI package released
  • All feeders/providers updates to use new kuksa-client release
  • Running latest released Broker/Server as needed

Note 2024-05-03: As KUKSA Server is deprecated we do not any longer test connection towards KUKSA Server as part of Release Testing, unless changes related to Server/VISS-functionality has been performed

Basic testing with Databroker (Insecure, No TLS)

~/kuksa-databroker$ cargo run --bin databroker -- --metadata data/vss-core/vss_release_4.0.json --insecure

Python Client test

Or use databroker-cli, just needed to check that dbc values are actually are set

erik@debian6:~/kuksa-python-sdk/kuksa-client$ kuksa-client grpc://127.0.0.1:55555


Test Client> setValue Vehicle.Speed 33
OK

Test Client> getValue Vehicle.Speed

CAN Provider

They rely on the client, so some testing is necessary. Two options exist, either build and install kuksa-client locally, or upload an alpha package to pypi. Testing with an uploaded package is preferable as that also tests that Pypi packaging works as expected.

Start DBC Feeder using default settings

erik@debian3:~/kuksa.val.feeders/dbc2val$ ./dbcfeeder.py

Let it run for a while, verify with Python client (or databroker CLI) that Vehicle.Speed change now and then (it takes some time to see the first change).

Test Client> getValue Vehicle.Speed                          
{
    "path": "Vehicle.Speed",
    "value": {
        "value": 77.0,
        "timestamp": "2023-07-20T13:17:26.946733+00:00"
    }
}

Test Client> getValue Vehicle.Speed
{
    "path": "Vehicle.Speed",
    "value": {
        "value": 54.0,
        "timestamp": "2023-07-20T13:17:33.924064+00:00"
    }
}

Databroker (TLS + Token)

erik@debian3:~/kuksa.val/kuksa_databroker$ cargo run --bin databroker -- --metadata ../data/vss-core/vss_release_4.0.json --insecure

erik@debian6:~/kuksa-databroker$ cargo run --bin databroker -- --metadata data/vss-core/vss_release_4.0.json --tls-cert certificates/Server.pem --tls-private-key certificates/Server.key --jwt-public-key certificates/jwt/jwt.key.pub

DBCFeeder

Change config (assuming you have kuksa.val in parallel)

tls = True
tls_server_name=localhost
token=../kuksa.val/jwt/provide-all.token
root_ca_path=../kuksa.val/kuksa_certificates/CA.pem

If you instead have kuksa-common:

tls = True
tls_server_name=localhost
token=../kuksa-common/jwt/provide-all.token
root_ca_path=../kuksa-common/tls/CA.pem

Run and check that no errors are reported

erik@debian3:~/kuksa.val.feeders/dbc2val$ ./dbcfeeder.py 
2023-07-26 11:27:56,387 INFO dbcfeeder: Using config: config/dbc_feeder.ini
2023-07-26 11:27:56,388 INFO dbcfeeder: Given root CA path: ../../kuksa.val/kuksa_certificates/CA.pem
2023-07-26 11:27:56,388 INFO dbcfeeder: Given TLS server name: localhost
2023-07-26 11:27:56,388 INFO dbcfeeder: Given token information: ../../kuksa.val/jwt/provide-all.token
2023-07-26 11:27:56,388 INFO dbcfeeder: DBC2VAL mode is: True
2023-07-26 11:27:56,388 INFO dbcfeeder: VAL2DBC mode is: False
...
2023-07-26 11:27:56,909 INFO dbcfeeder: Starting to process CAN signals
2023-07-26 11:27:56,914 INFO dbcfeeder: Number of VSS messages sent so far: 1, queue max size: 8
2023-07-26 11:27:56,920 INFO dbcfeeder: Number of VSS messages sent so far: 2, queue max size: 8
...

Bidirectional DBC Feeder (TLS, Token)

Keep broker running. Start dbcfeeder with changed config like above

erik@debian3:~/kuksa.va
erik@debian3:~/kuksa.val.feeders/dbc2val$ ./dbcfeeder.py --val2dbc --dbc2val --use-socketcan

If failures, make sure net-tools is installed

erik@debian3:~/kuksa.val.feeders/dbc2val$ sudo apt install net-tools

Test with client, possibly like here using installed kuksa-client

erik@debian3:~$ kuksa-client grpcs://127.0.0.1:55555  --cacertificate ../kuksa.val/kuksa_certificates/CA.pem --tls-server-name Server
Welcome to Kuksa Client version 0.4.0
...
Secure gRPC channel connected.               
Test Client> authorize kuksa.val/jwt/actuate-provide-all.token 
"Authenticated"

Test Client> setTargetValue Vehicle.Body.Mirrors.DriverSide.Pan 81
OK

Test Client> getValue Vehicle.Body.Mirrors.DriverSide.Pan         
{
    "path": "Vehicle.Body.Mirrors.DriverSide.Pan",
    "value": {
        "value": 80,
        "timestamp": "2023-07-26T11:16:13.981634+00:00"
    }
}

Test Client>

Server (TLS, Token)

handled by smoke test at https://github.com/eclipse/kuksa.val/wiki/Release-Testing

Docker

This shall preferably be tested twice, first with local builds, then with official ones!

Building

Build a local docker:

docker build -f Dockerfile --progress=plain --build-arg TARGETPLATFORM=linux/amd64 -t can-provider:latest .

Testing

Start KUKSA Databroker with TLS/Token. Edit dbcfeeder config like this (or create a copy first)

(Yes, we might have been able to use some default ones existing embedded in kuksa-client for historical reasons, but that is not so interesting)

port = 55555
tls = True
root_ca_path=/cert/CA.pem
tls_server_name=localhost
token=/jwt/provide-all.token

Then run something like:

Local docker built as above

erik@debian3:~/vehicle_signal_specification$ docker run --net=host -e LOG_LEVEL=INFO -v /home/erik/kuksa.val/jwt:/jwt -v /home/erik/kuksa.val/kuksa_certificates:/cert -v /home/erik/kuksa.val.feeders/dbc2val/config:/config can-provider:latest --config /config/dbc_feeder_docker.ini

Latest main

erik@debian3:~/vehicle_signal_specification$ docker run --net=host -e LOG_LEVEL=INFO -v /home/erik/kuksa.val/jwt:/jwt -v /home/erik/kuksa.val/kuksa_certificates:/cert -v /home/erik/kuksa.val.feeders/dbc2val/config:/config ghcr.io/eclipse-kuksa/kuksa-can-provider/can-provider:main --config /config/dbc_feeder_docker.ini
Clone this wiki locally