impl: backend design change

[arkjedrz]

• Created new KvsBackend API.
  • No longer filesystem-specific.
• Added KvsBackendRegistry.
  • KvsBuilder accepts backend parameters using KvsMap.
• JsonBackend used as default.
• Built-in backend access is not hidden.
• backend_registration example.
• PlantUML-based class diagram.
• Updated tests.

[Copilot]

Pull Request Overview

This PR implements a significant backend design change by introducing a generic KVS backend system that separates the storage layer from the core KVS functionality. It replaces the filesystem-specific architecture with a pluggable backend system using the KvsBackend trait and KvsBackendRegistry.

• Introduces KvsBackend trait and KvsBackendRegistry for pluggable storage backends
• Replaces direct filesystem operations with backend abstraction layer
• Updates KVS builder to use backend parameters instead of direct filesystem paths
• Removes deprecated file path APIs and updates examples/tests to use new backend system

Reviewed Changes

Copilot reviewed 24 out of 24 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/rust/rust_kvs/src/lib.rs	Updates prelude exports and type aliases to support new backend architecture
src/rust/rust_kvs/src/kvs_backend_registry.rs	Implements new backend registry system for managing pluggable storage backends
src/rust/rust_kvs/src/kvs_backend.rs	Defines new KVS backend trait interface replacing filesystem-specific operations
src/rust/rust_kvs/src/kvs_builder.rs	Refactors builder to use backend parameters instead of direct filesystem paths
src/rust/rust_kvs/src/kvs.rs	Updates KVS implementation to use backend abstraction instead of direct file operations
src/rust/rust_kvs/src/json_backend.rs	Converts JSON backend to implement new backend trait with factory pattern
tests/rust_test_scenarios/src/helpers/	Updates test helpers to use new backend parameter system
tests/python_test_cases/tests/test_cit_snapshots.py	Updates tests to check file existence rather than API return values
src/rust/rust_kvs_tool/src/kvs_tool.rs	Removes deprecated filename APIs and updates to use backend parameters
src/rust/rust_kvs/examples/	Updates all examples to use new backend parameter format
docs/class_diagram.puml	Adds PlantUML class diagram showing new backend architecture

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.3.0) and connecting to it...
INFO: Invocation ID: d1995115-3599-4103-88b4-4c3549c3198d
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
DEBUG: Rule 'rust_qnx8_toolchain+' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-oEubHgeZDdT0svMmBKJx7c3/2TdSI/vfwRUyDn+TPGA="
DEBUG: Repository rust_qnx8_toolchain+ instantiated at:
  <builtin>: in <toplevel>
Repository rule http_archive defined at:
  /home/runner/.bazel/external/bazel_tools/tools/build_defs/repo/http.bzl:394:31: in <toplevel>
Computing main repo mapping: 
Computing main repo mapping: 
WARNING: For repository 'rules_rust', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'rules_cc', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'platforms', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
Computing main repo mapping: 
Loading: 
Loading: 4 packages loaded
Loading: 4 packages loaded
    currently loading: 
Analyzing: target //:license-check (5 packages loaded, 0 targets configured)
Analyzing: target //:license-check (5 packages loaded, 0 targets configured)

Analyzing: target //:license-check (77 packages loaded, 9 targets configured)

Analyzing: target //:license-check (92 packages loaded, 9 targets configured)

Analyzing: target //:license-check (156 packages loaded, 2616 targets configured)

Analyzing: target //:license-check (162 packages loaded, 6985 targets configured)

Analyzing: target //:license-check (162 packages loaded, 6985 targets configured)

INFO: Analyzed target //:license-check (165 packages loaded, 9001 targets configured).
[13 / 14] [Prepa] Generating Dash formatted dependency file ...
INFO: From Generating Dash formatted dependency file ...:
INFO: Successfully converted 65 packages from Cargo.lock to bazel-out/k8-fastbuild/bin/formatted.txt
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 22.982s, Critical Path: 0.42s
INFO: 14 processes: 5 disk cache hit, 9 internal.
INFO: Build completed successfully, 14 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

[github-actions]

The created documentation from the pull request is available at: docu-html

[tizava]

With the proposed API, the user always have to wait until whole KVS is populated only then values are accessible.
Why not to allow direct access to the value and satisfy requirements for earliest possible availability?
With restriction that only read access is possible eg. load_value(key: string): KvsValue

[arkjedrz]

Yes, currently it is assumed that storage is fully memory-mapped. You can add it as a topic for requirements discussion.

[tizava]

Maybe I didn't get the whole idea behind the snapshots, my understanding and some questions:

• User can create snapshot in order to "conserve" the current values
• After values in working copy were modified, user can restore the "conserved" values with snapshot_restore(instance_id: InstanceId, snapshot_id: SnapshotId)
• Is the snapshot_restore() intended to overwrite the working copy? I see that it return KvsMap so probably not.
• Do we need the snapshot_restore() at all? load_kvs() can take snapshot ID as well
• Who is taking care of book-keeping the SnapshotIds? If this is the backend, then we need something like get_snapshots() which will return list of existing snapshot IDs
• snapshot_delete() will be needed as well
• How are the snapshots created? Do we need something like snapshot_create()?

[arkjedrz]

• snapshot_restore is intended to overwrite current state, You still need to flush.
• No strong opinion on whether we need snapshot_restore at all. It's just load with additional error checks, we can also provide it as an already implemented trait method, since I cannot imagine other behavior than current.
• SnapshotId behavior should be documented. Right now it is assumed that "0" means current, and "1", "2", "123" means 1 ago, 2 ago, 123 ago.
• snapshot_delete is already required, but not implemented. This function will break the SnapshotId behavior explained above, we'll need to reconsider.
• We don't need snapshot_create, since flush stores current state as "0". Previously existing snapshots are rotated ("0"->"1", "1"->"2") or removed (if snapshot_max_count=3, then "2" is removed).

Those are valid points, but should be taken into consideration once requirements are modified.