You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Standards/scs-0003-v1-sovereign-cloud-standards-yaml.md
+19-53Lines changed: 19 additions & 53 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -86,22 +86,23 @@ While instructive, this view is still a bit simplified. Let's get more precise n
86
86
A statement about the subject that can be evaluated unambiguously to be either satisfied or not. The result is either `PASS` or `FAIL`, or—if the test could not be performed—`DNF` (did not finish).
87
87
A test case can be as simple as "the subject conforms to standard X", but a standard can also be decomposed into multiple test cases, which can then be reported on (also to the customers) individually.
88
88
This latter option has the advantage that we can show explicitly if the subject complies with optional parts of the standard.
89
-
3._Check_:
90
-
A script that determines and reports the results of certain test cases. The report is printed to stdout, and each test case is reported as a single line of the form `testcase-id: [PASS/FAIL]`. The result `DNF` is not reported. Lines of other forms are permissible and will be ignored.
91
-
We also occasionally extend the concept of _check_ to manual audits.
92
-
4._Module_:
93
-
A collection of test cases and corresponding checks, together with additional meta information such as the result lifetime, description, and a list of tags for a test case.
94
-
Ultimately, we aim to specify one module for each version of each standard: the module translates the standard into something measurable and, ideally, executable to be used for certification.
95
-
5._Selector (expression)_:
96
-
An expression used to select test cases by referring to the tags that must (or must not) be present.
97
-
6._Target_:
98
-
A named collection of test cases specified using selector expressions.
89
+
3._Script_:
90
+
A script that determines and reports the results of certain test cases,
91
+
which are specified with the script, together with additional meta information such as the result lifetime, and a description for each test case.
92
+
The report is printed to stdout, and each test case is reported as a single line of the form `testcase-id: [PASS/FAIL/ABORT]`.
93
+
Lines of other forms are permissible and will be ignored.
94
+
We also occasionally extend the concept of _script_ to manual audits.
95
+
4._Target_:
96
+
A named collection of test cases.
99
97
Ultimately, the certification of a subject always depends on a designated "main" target; all its test cases must be passed for the certificate to be awarded.
100
98
Further targets can be used to report on optional aspects of the certificate, such as particularly good security and encryption measures.
101
-
7._(Certificate-scope) version_:
102
-
A collection of modules and a collection of targets, one of them being "main".
99
+
5._Module_:
100
+
A collection of targets.
101
+
Ultimately, we aim to specify one module for each version of each standard: the module translates the standard into something measurable and, ideally, executable to be used for certification.
102
+
6._(Certificate-scope) version_:
103
+
A collection of modules. Like a module, the version has targets, but they are implicitly given by taking the union of the targets of all its modules.
103
104
Note that a collection of modules can again be construed as a (larger) module. We opt to use one module per standard version, as mentioned above, in order to make commonalities between certificate-scope versions explicit.
104
-
8._Certificate scope_:
105
+
7._Certificate scope_:
105
106
A list of certificate-scope versions.
106
107
107
108
Having introduced these concepts, we can now get even more precise by defining the actual specification in YAML format.
@@ -120,6 +121,7 @@ The certification YAML _MUST_ contain the following keys:
|`name`| String | Full name of this certificate scope |`SCS-open KaaS`|
122
123
|`url`| String | Valid URL to the latest raw version of this document |`https://raw.githubusercontent.com/SovereignCloudStack/standards/main/Tests/scs-open-kaas.yaml`|
124
+
|`scripts`| Array of maps | List of script descriptors (described below) | (see below) |
123
125
|`modules`| Array of maps | List of module descriptors (described below) | (see below) |
124
126
|`timeline`| Array of maps | List of timeline entries (described below) | (see below) |
125
127
|`versions`| Array of maps | List of version descriptors (described below) | (see below) |
@@ -154,7 +156,6 @@ then a certificate of that prerequisite scope has to be presented before the cer
|`name`| String | name of this module |`Flavor naming v3`|
213
182
|`url`| String | Valid URL to relevant documentation (usually a standard document) |`https://docs.scs.community/standards/scs-0100-v3-flavor-naming`|
214
183
|`parameters`| List | List of parameters that the checks in this module might use |`[image_spec]`|
215
-
|`run`| Array | List of all checks that should be run; each entry being a check descriptor | (see below) |
216
-
|`testcases`| Array | List of all test cases; each entry being a test-case descriptor | (see below) |
184
+
|`targets`| Map of maps | required: this maps target names to lists of testcases |`main: [tc1, tc2]`|
217
185
218
186
The parameters specified here will be added to the variable assignment for all check tools that belong to this module, so they will be substituted in the same way.
219
187
The values to these parameters must be provided in the include descriptor as explained above.
@@ -223,13 +191,14 @@ Using parameters offers two advantages:
223
191
- they may show up in the automatically generated documentation, whereas the check tools themselves probably won't.
224
192
- multiple versions of a standard can be represented using the same module, if everything that changes between versions can be captured by the parameters.
225
193
226
-
### Check descriptor
194
+
### Script descriptor
227
195
228
-
The following fields are valid for every check descriptor:
196
+
The following fields are valid for every script descriptor:
0 commit comments