CLI support for V2

[petervolvowinz]

Any time frame when this will be supported ?

[lukasmittag]

Currently, I would say not planned for the near future. If anyone else outside of the core team wants to contribute that. Highly appreciated as well (we would support with reviewing and bring the code in).

[rafaeling]

Databroker also supports reflection for kuksa.val.v2, so grpcurl could be use for some methods, not for OpenProviderStream though.
https://github.com/eclipse-kuksa/kuksa-databroker/wiki/Release-Testing#testing-databroker-kuksavalv2-api-methods-with-grpcurl

[harvinderRathore]

Proposal to Work on CLI Support for V2

I would like to start working on adding CLI support for kuksa.val.v2. Based on my review of the current CLI and the V2 API definitions, here is the proposed plan:

Step 1: Analysis

• Review the existing CLI implementation for V1.
• Compare the proto definitions of V1 (proto/kuksa/val/v1/val.proto) and V2 (proto/kuksa/val/v2/val.proto) to identify differences in request/response structures and method names.
• Identify which CLI commands should be supported first (get, set, subscribe, metadata).

Step 2: Design

• Introduce a --v2 flag to enable CLI commands to target V2 endpoints while preserving backward compatibility with V1.
• Map CLI commands to V2 RPCs:
  • get → GetDataPoints
  • set → SetDataPoints
  • subscribe → Subscribe
  • metadata → handled if supported in V2
• Keep the same CLI syntax where possible, with only minimal differences if required by V2 API changes.

Step 3: Implementation

• Generate and integrate Rust client stubs for kuksa.val.v2 using tonic.
• Extend CLI logic to support V2 paths when the --v2 flag is used.
• Implement the core commands for V2 in parallel with existing V1 code.

Questions for the maintainers

• Should the CLI support both V1 and V2 in parallel, or move directly to V2-only?
• Is it acceptable to introduce an explicit --v2 flag, or should auto-detection of broker version be considered?
• Which commands are highest priority for initial implementation (get and set only, or should subscribe and metadata be included as well)?

[lukasmittag]

Step 2: Design

Introduce a --v2 flag to enable CLI commands to target V2 endpoints while preserving backward compatibility with V1.
Map CLI commands to V2 RPCs:
get → GetDataPoints
set → SetDataPoints
subscribe → Subscribe
metadata → handled if supported in V2
Keep the same CLI syntax where possible, with only minimal differences if required by V2 API changes.

I would suggest to use the v2 wrapped in the official rust sdk

get → https://github.com/eclipse-kuksa/kuksa-rust-sdk/blob/5e4ad7c93cb3b6bc1412951d5a5501aa238b2dd1/kuksa-rust-sdk/src/kuksa/val/v2/mod.rs#L224C14-L224C23
set/publish → https://github.com/eclipse-kuksa/kuksa-rust-sdk/blob/5e4ad7c93cb3b6bc1412951d5a5501aa238b2dd1/kuksa-rust-sdk/src/kuksa/val/v2/mod.rs#L300C14-L300C27
set/actuate → https://github.com/eclipse-kuksa/kuksa-rust-sdk/blob/5e4ad7c93cb3b6bc1412951d5a5501aa238b2dd1/kuksa-rust-sdk/src/kuksa/val/v2/mod.rs#L349
subscribe → Subscribe
metadata → https://github.com/eclipse-kuksa/kuksa-rust-sdk/blob/5e4ad7c93cb3b6bc1412951d5a5501aa238b2dd1/kuksa-rust-sdk/src/kuksa/val/v2/mod.rs#L559
provide → https://github.com/eclipse-kuksa/kuksa-rust-sdk/blob/5e4ad7c93cb3b6bc1412951d5a5501aa238b2dd1/kuksa-rust-sdk/src/kuksa/val/v2/mod.rs#L605 this needs to be implemented first (in the rust sdk) if we want to add this. For debugging purposes it would be nice

For usage examples have a look at https://github.com/eclipse-kuksa/kuksa-rust-sdk/blob/main/databroker-examples/examples/kuksa_val_v2.rs

[lukasmittag]

Should the CLI support both V1 and V2 in parallel, or move directly to V2-only?

No, since the v1 is still a valid interface to the broker and not deprecated we need it in parallel if possible

Is it acceptable to introduce an explicit --v2 flag, or should auto-detection of broker version be considered?

This would be okay to have a flag currently it is under the option of -p --protocol and then sdv.databroker.v1 and kuksa.vak.v1 so this can be extended I guess

Which commands are highest priority for initial implementation (get and set only, or should subscribe and metadata be included as well)?

To have a mvp you at lest need someone that publishes and someone that gets things metadata would be nice but is optional I guess. Once get works add subscribe
so in my PoV:

1. publish
2. get
3. subscribe
4. provide
5. actuate
6. metadata