Requirements improvements

[arkjedrz]

Those are my notes from requirements analysis - this should be discussed.

NOTES AND OBSERVATIONS

Other languages

Requirement 3 in Rationale mention "C++, Rust and other".
This should be restated - only C++ and Rust.

Link to rationale

Expected environment

QNX is the first priority, Linux is second.

Inter-process communication

Inter-process communication should be disallowed.

Compile-time/runtime

Should terms "compile-time" and "runtime" be used for requirements?
Maybe "constant", "determined at runtime", "parametrizable" should be used?

Mocks

Mocks are not mentioned in requirements.
At least high-level expectations should be described.

Late instantiation of KVS instances

For Rust implementation there's no distinction between init and get.
This might cause KVS instance to be initialized during program run.

Expected behavior should be written down.

Approach to instantiation of KVS instances

For Rust implementation it's required to always use same set of parameters.
Expected behavior should be written down.

Config file init

Config file init is not mentioned in requirements.

Load modes

Load modes (KvsDefaults, KvsLoad) are not described in requirements.

Many existing APIs are not described by requirements

Missing in Kvs:

• reset - "Storage reset".
• reset_key - "Value under key reset".
• get_all_keys - not sure this has to be defined.
• key_exists - "Key exists check".
• get_value - "Value retrieval".
• is_value_default - defined under "Default Value Retrieval"?
• set_value - "Value set".
• remove_key - "Value reset".
• snapshot_count - "Snapshots count"
• snapshot_max_count - "Snapshots count"

Missing IDs definitions: InstanceId and SnapshotId.
Those are trivial implementation-wise, but should be described.
API is missing snapshot_remove, and then SnapshotId behavior becomes non-trivial (described later).

C++ & Rust Interoperability ❓

The Key-Value-Storage shall provide access through both C++ and Rust interfaces.

I would separate a notion of storage and implementation.
Storage - files, databases, cloud, etc.
Implementation - libraries, backends, interfaces.
Otherwise it's not always clear what's being discussed.
In this case - every implementation shall be able to access same storage.

Maximum Size ❓

The Key-Value-Storage shall support specification of its maximum size at compile time.

Maybe app/env should decide such limits (e.g., cgroups).
Why compile time?
This requirement is at conflict with "Configure limits via file".

Multiple KVS per Software Architecture Element ❓

The Key-Value-Storage shall allow instantiating multiple independent stores per software architecture element.

Current Rust KVS implementation allows maximum of 10 KVS instances.
This is to prevent additional allocations at runtime - but this is done elsewhere, beyond init.
This limitation should either be removed or placed directly in requirements.

Back to note from "C++ & Rust Interoperability" - it's not clear here that requirement is for KVS implementation, since storage shouldn't exactly care.

Supported Datatypes (Keys) ✅

The Key-Value-Storage shall support UTF-8 encoded strings as valid key types.

Supported Datatypes (Values) ✅

The Key-Value-Storage shall support storing both primitive and non-primitive datatypes as values.
The supported datatypes shall match those used by the IPC feature.

Default Values ✅

The Key-Value-Storage shall support predefined default values for keys.

Default Value Retrieval ✅

The Key-Value-Storage shall support retrieving the default value associated with a key.

Default Value Reset ✅

The Key-Value-Storage shall support resetting a single key or all keys to their respective default values.

Persistency ✅

The Key-Value-Storage shall persist stored data and provide an API to explicitly trigger persistence.

Integrity Check ✅

The Key-Value-Storage shall detect and report data corruption.
Note: Implementation depends on AoUs.

Versioning ❌

The Key-Value-Storage shall support versioning for different layout configurations.

Not implemented yet.

Update Mechanism ❌

The Key-Value-Storage shall implement mechanisms to upgrade from one version to another, including multi-version jumps.

Not implemented yet.

Snapshots ✅❌

The Key-Value-Storage shall support explicit creation of snapshots identified by unique IDs and allow rollback to previous snapshots.
Snapshots shall also be deletable.

Snapshots support is implemented.

"Snapshots shall also be deletable." -> this should be a separate requirement.
This will require decision on how to handle SnapshotId.
E.g., should removal of ID=1 cause other snapshots to be rotated left?

Imagine snapshots: [A=0, B=1, C=2, D=3].
Remove B=1.
Should the output be:
[A=0, C=2, D=3]?
[A=0, C=1, D=2]?

Tooling ✅

The Key-Value-Storage shall provide tooling support for viewing and modifying key-value pairs during development and debugging.

Variant management support ❌

The Key-Value-Storage shall ensure compatibility across different architectures and versions.

Not implemented yet.

Set default key values via file ✅

The Key-Value-Storage shall support the configuration of default key values using an external file.

Configure limits via file ❌

The Key-Value-Storage shall support the configuration of memory and other resource limits via a configuration file.

Not implemented yet.
This might not be in scope of persistency - e.g., cgroups can be used.

Store persistent data ✅

The Key-Value-Storage shall support storing and loading its data to and from persistent storage.

Shouldn't this requirement be merged with "Persistency"?

Support engineering mode ❌

The Key-Value-Storage shall an engineering (developer) mode.
The engineering mode shall allow unrestricted data access.

Not implemented yet.
Should that be defined at compile-time?

Support field mode ❌

The Key-Value-Storage shall a field mode.
The field mode should enforce the most restrictive data access controls feasible.

I need additional explanation for this requirement.

Provide an async API ❌

The Key-Value-Storage shall provide an asynchronous API for accessing and manipulating data.

Not implemented yet.

Separate data stores ❌

The Key-Value-Storage shall ensure that only authorized components can access individual data stores.

Not implemented yet.

Data-change events ❌

The Key-Value-Storage shall provide an API that allows for the registration of callback functions.
These callbacks shall be invoked in response to specific events, such as when keys are changed or removed.

Not implemented yet, nor should be.
This should be implemented by app.

Fast access ❌❌❌

The Key-Value-Storage shall ensure that key operations are completed within 5 milliseconds.

This requirement is invalid and impossible to satisfy in all cases.

Intra-Process Data Access ✅

The Key-Value-Storage shall support concurrent intra-process data access.

What's the rationale behind this requirement?

Persistency Error handling

The application shall handle if the feature persistency is not available.

Application deadlock

The application shall be designed in a way that deadlocks are avoided.

Application execution

The execution of persistency shall not be blocked by the application.