-
Notifications
You must be signed in to change notification settings - Fork 22
Release Testing
Release testing is done for components in status Beta/production/stable/mature at https://github.com/eclipse/kuksa.val/wiki/KUKSA.val-Component-Maturity.
- Kuksa-client PyPI package released
- All feeders/providers updates to use new kuksa-client release
- Running latest released Broker/Server as needed
erik@debian3:~/kuksa.val/kuksa_databroker$ cargo run --bin databroker -- --metadata ../data/vss-core/vss_release_4.0.json --tls-cert ../kuksa_certificates/Server.pem --tls-private-key ../kuksa_certificates/Server.key --jwt-public-key ../kuksa_certificates/jwt/jwt.key.pub
Change config
--- a/dbc2val/config/dbc_feeder.ini
+++ b/dbc2val/config/dbc_feeder.ini
-tls = False
+tls = True
-# tls_server_name=localhost
+tls_server_name=localhost
-# token=../../kuksa.val/jwt/provide-all.token
+token=../../kuksa.val/jwt/provide-all.token
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
...
Keep broker running. Start dbcfeeder with changed config like above
erik@debian3:~/kuksa.val.feeders/dbc2val$ sudo ./createvcan.sh vcan0
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 [--ip 127.0.0.1 --port 55555 --protocol grpc](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>
See smoke test at https://github.com/eclipse/kuksa.val/wiki/Release-Testing
CSV provider does not support authentication
erik@debian3:~/kuksa.val/kuksa_databroker$ cargo run --bin databroker -- --metadata ../data/vss-core/vss_release_4.0.json --tls-cert ../kuksa_certificates/Server.pem --tls-private-key ../kuksa_certificates/Server.key
Run and expect something like below
erik@debian3:~/kuksa.val.feeders/csv_provider$ python provider.py --cacertificate /home/erik/kuksa.val/kuksa_certificates/CA.pem --tls-server-name Server
INFO:kuksa_client.grpc:Using TLS with Root CA from /home/erik/kuksa.val/kuksa_certificates/CA.pem
INFO:kuksa_client.grpc:No client certificates provided, mutual TLS not supported!
INFO:kuksa_client.grpc.aio:Establishing secure channel
INFO:kuksa_client.grpc.aio:Using TLS server name Server
INFO:root:Starting to apply the signals read from signals.csv.
INFO:root:Update target value of Vehicle.Chassis.ParkingBrake.IsEngaged to false
INFO:root:Update current value of Vehicle.Chassis.ParkingBrake.IsEngaged to true
INFO:root:Update current value of Vehicle.Speed to 27
INFO:root:Update current value of Vehicle.Speed to 48
INFO:root:Update current value of Vehicle.Speed to 24
Test basically as described in https://github.com/eclipse/kuksa.val.feeders/blob/main/dds2val/README.md
Start KML Replay. Start DDS Feeder
erik@debian3:~/kuksa.val.feeders/dds2val$ VDB_ROOT_CA_PATH=/home/erik/kuksa.val/kuksa_certificates/CA.pem VDB_TLS_SERVER_NAME=Server python3 ddsprovider.py
Verify with client that latitude updates frequently
Test Client> getValue Vehicle.CurrentLocation.Latitude
{
"path": "Vehicle.CurrentLocation.Latitude",
"value": {
"value": 9.90499,
"timestamp": "2023-07-26T11:42:48.513418+00:00"
}
}
handled by smoke test at https://github.com/eclipse/kuksa.val/wiki/Release-Testing
This shall preferably be testes twice, first with local builds, then with official ones!
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:
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.val.feeders/dbc2val:0.4 --config /config/dbc_feeder_docker.ini
Build locally
docker build -f Dockerfile --progress=plain --build-arg TARGETPLATFORM=linux/amd64 -t csv-provider:latest .
Run something like (against broker using TLS but not auth):
erik@debian3:~/vehicle_signal_specification$ docker pull ghcr.io/eclipse/kuksa.val.feeders/csv-provider:0.4
erik@debian3:~/vehicle_signal_specification$ docker run --net=host -e LOG_LEVEL=INFO -v /home/erik/kuksa.val/kuksa_certificates:/cert ghcr.io/eclipse/kuksa.val.feeders/csv-provider:0.4 --cacertificate /cert/CA.pem --tls-server-name Server
INFO:kuksa_client.grpc:Using TLS with Root CA from /cert/CA.pem
INFO:kuksa_client.grpc:No client certificates provided, mutual TLS not supported!
INFO:kuksa_client.grpc.aio:Establishing secure channel
INFO:kuksa_client.grpc.aio:Using TLS server name Server
INFO:root:Starting to apply the signals read from signals.csv.
INFO:root:Update target value of Vehicle.Chassis.ParkingBrake.IsEngaged to false
INFO:root:Update current value of Vehicle.Chassis.ParkingBrake.IsEngaged to true
INFO:root:Update current value of Vehicle.Speed to 27
INFO:root:Update current value of Vehicle.Speed to 48
INFO:root:Update current value of Vehicle.Speed to 24
erik@debian3:~/kuksa.val.feeders/gps2val$ docker run -it -p 2948:2948/udp --net=host -v /home/erik/kuksa.val/kuksa_certificates/:/cert ghcr.io/eclipse/kuksa.val.feeders/gps:0.4 --port 55555 --protocol grpc --ip 127.0.0.1 --cacertificate /cert/CA.pem --tls-server-name Server
or with port 2949
docker run -it -p 2949:2949/udp --net=host -v /home/erik/kuksa.val/kuksa_certificates/:/cert gpsd_feeder --port 55555 --protocol grpc --ip 127.0.0.1 --cacertificate /cert/CA.pem --tls-server-name Server --gpsd_port 2949
In general, if you see something like:
2023-12-14 08:01:28,291 INFO gpsfeeder: Number of VSS messages sent so far: 1
2023-12-14 08:01:28,315 INFO gpsfeeder: Number of VSS messages sent so far: 2
2023-12-14 08:01:29,355 INFO gpsfeeder: Number of VSS messages sent so far: 4
2023-12-14 08:01:29,438 INFO gpsfeeder: Number of VSS messages sent so far: 8
2023-12-14 08:01:30,714 INFO gpsfeeder: Number of VSS messages sent so far: 16
2023-12-14 08:01:33,085 INFO gpsfeeder: Number of VSS messages sent so far: 32
... then life is fine!
Alpha component, so we just test that it complains in an ordered fashion. No good test description exists
erik@debian3:~/kuksa.val.feeders/gps2val$ docker run -it --net=host ghcr.io/eclipse/kuksa.val.feeders/someip-feeder:0.4
...
2023-06-28 12:18:06.169767 [info] SOME/IP routing ready.
# ActuatorSubscriber::Run: [info] Not connected
# ActuatorSubscriber::Run: [info] Not connected
# DataBrokerFeeder::Run: [info] Connecting to data broker [localhost:55555] ...
# ActuatorSubscriber::Run: [info] Not connected
...