Skip to content

Commit bbaf461

Browse files
committed
persistency: Feature request for KVS
Initial draft
1 parent eae387b commit bbaf461

File tree

1 file changed

+117
-0
lines changed
  • docs/features/persistency/key-value-storage

1 file changed

+117
-0
lines changed

docs/features/persistency/key-value-storage/index.rst

+117
Original file line numberDiff line numberDiff line change
@@ -14,3 +14,120 @@
1414
1515
Key-value Storage
1616
#################
17+
18+
- Key-Value Storage is needed because there are (legacy) applications which require a KVS
19+
- There are multiple Key-Value Storages allowed per application
20+
- There must be an update mechanism from different versions of a KVS to another version
21+
- When are modifications persisted? Configurable?
22+
- The same KVS should be read/writeable from C++ & Rust.
23+
- Supported Datatypes: Primitive Datatypes & Non-Primitive Datatypes; To be coordinated with IPC/Communication CTF, to use the same datatypes
24+
- Tooling to modify/access content of KVS "from the outside"
25+
- KVS should store default values
26+
- Integrity of the KVS should be checked
27+
28+
.. document:: [Your Feature Name]
29+
:id: DOC__Your_Feature_Name
30+
:status: draft
31+
:safety: ASIL_D
32+
:tags: contribution_request, feature_request
33+
34+
.. attention::
35+
The above directive must be updated according to your Feature.
36+
37+
- Modify ``name`` to be your Feature Name
38+
- Modify ``id`` to be your Feature Name in upper snake case preceded by ``DOC_``
39+
- Adjust ``status`` to be ``valid``
40+
- Adjust ``asil`` according to your needs
41+
- Extend ``tags`` according to your needs, but please keep two default tags there
42+
43+
44+
Feature flag
45+
============
46+
47+
To activate this feature, use the following feature flag:
48+
49+
``experimental_[your_feature_name]``
50+
51+
.. note::
52+
The feature flag must reflect the feature name in snake_case. Further, it is prepended with ``experimental_``, as
53+
long as the feature is not yet stable.
54+
55+
56+
Abstract
57+
========
58+
59+
[A short (~200 word) description of the contribution being addressed.]
60+
61+
62+
Motivation
63+
==========
64+
65+
[Clearly explain why the existing platform/project solution is inadequate to address the topic that the Feature Request solves.]
66+
67+
.. note::
68+
The motivation is critical for Feature Requests that want to change the existing features or infrastructure.
69+
It should clearly explain why the existing solution is inadequate to address the topic that the Feature Request solves.
70+
Feature Request submissions without sufficient motivation may be rejected.
71+
72+
73+
Rationale
74+
=========
75+
76+
[Describe why particular design decisions were made.]
77+
78+
79+
.. note::
80+
The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
81+
82+
83+
Specification
84+
=============
85+
86+
[Describe the requirements, architecture of any new feature.] or
87+
[Describe the change to requirements, architecture, implementation, process, documentation, infrastructure of any change request.]
88+
89+
.. note::
90+
A Feature Request shall specify the stakeholder requirements as part of our platform/project.
91+
Thereby the :need:`RL_technical_lead` will approve these requirements as part of accepting the Feature Request (e.g. merging the PR with the Feature Request).
92+
93+
94+
Backwards Compatibility
95+
=======================
96+
97+
[Describe potential impact (especially including safety and security impacts) and severity on pre-existing platform/project elements.]
98+
99+
100+
Security Impact
101+
===============
102+
103+
[How could a malicious user take advantage of this new feature?]
104+
105+
.. note::
106+
If there are security concerns in relation to the Feature Request, those concerns should be explicitly written out to make sure reviewers of the Feature Request are aware of them.
107+
108+
109+
110+
Safety Impact
111+
=============
112+
113+
[How could the safety be impacted by the new feature?]
114+
115+
.. note::
116+
If there are safety concerns in relation to the Feature Request, those concerns should be explicitly written out to make sure reviewers of the Feature Request are aware of them.
117+
ToDo - Link to the Safety Impact Method
118+
119+
[What is the expected ASIL level?]
120+
[What is the expected classification of the contribution?]
121+
122+
.. note::
123+
Use the component classification method here to classfiy your component, if it shall to be used in a safety context: (TODO: add link to component classification).
124+
125+
126+
License Impact
127+
==============
128+
129+
[How could the copyright impacted by the license of the new contribution?]
130+
131+
132+
How to Teach This
133+
=================

0 commit comments

Comments
 (0)