Replace yaml scopes by regular standards

Standards/scs-0001-v1-sovereign-cloud-standards.md

@@ -100,6 +100,7 @@ The second digit in `XXXX` describes the track where the document belongs:
 | KaaS | 2 |
 | IAM | 3 |
 | Ops | 4 |
+| Scopes | 5 |
 
 In addition to the number, each document has the following metadata,
 embedded in the markdown header.

Standards/scs-0003-v2-sovereign-cloud-standards-testing.md

@@ -0,0 +1,94 @@
+---
+title: Sovereign Cloud Standards Testing
+type: Procedural
+status: Draft
+track: Global
+replaces:
+- scs-0003-v1-sovereign-cloud-standards-yaml.md
+description: |
+  SCS-0003 defines concepts central to testing SCS standards and regulates how results may
+  be obtained and aggregated.
+---
+
+## Introduction
+
+This standard defines concepts central to testing SCS standards and regulates how results may
+be obtained and aggregated.
+
+## Concept definitions
+
+A standard can be viewed as a collection of propositions that "must" (or "should") be satisfied
+by a test subject (cloud or cluster). The standard is satisfied if all "must" propositions are
+satisfied.
+
+A _testcase_ is a collection of propositions that coincide with respect to the following properties:
+
+- whether they can be tested automatically with normal user permissions;
+- how often they need to be tested (daily, weekly, monthly, annually);
+- whether they are required ("must").
+
+We unambiguously refer to a testcase using a composite identifier consisting of two parts:
+
+- the _scope_: in the context of this standard, just an identifier of a namespace;
+  for example: `scs-compatible-iaas` (or a UUID)
+- the _testcase id_, for example `scs-0100-syntax-check` or `scs-0101-fips-test`.
+
+The scope part is usually clear from the context and therefore omitted.
+
+A _test_ is a testcase or a collection of tests. We refer to a test using the same kind of
+composite identifier as for a testcase.
+
+For instance, if we have testcases `scs-0100-syntax-check` and `scs-0100-semantics-check`,
+we could define the test `scs-0100-v3` as the collection consisting of these two testcases.
+Given further tests `scs-0101-v1`, `scs-0102-v1` etc., we could define the test `scs-0501-v4`
+as the collection consisting of `scs-0100-v3`, `scs-0101-v1`, `scs-0102-v1` etc.
+
+A test can be viewed as a collection of propositions; namely, all propositions of all testcases
+that are part of the test.
+
+The _result_ of a test is one of the following values:
+
+- `FAIL`: it could be verified that at least one of its propositions is not satisfied;
+- `MISS` (missing): for at least one of its propositions, it was not (recently) attempted to verify it;
+- `DNF` (did not finish): for at least one of its propositions, it could not be verified whether it is satisfied;
+- `PASS`: it could be verified that all its propositions are satisfied.
+
+If multiple items apply, we always opt for the topmost one.
+
+A _test report_ is a data structure that contains the following information:
+
+- UUID,
+- Subject: the name of the test subject,
+- Scope: the scope of all the testcases referred to in this score card,
+- Creator: who created the report (name of person or version of the software),
+- Check date: when the test was performed,
+- Test results: a mapping that maps testcase ids to results.
+- Log: free-form text that details the test run.
+
+A _check script_ is a computer program that tests one or more testcases and produces a test report.
+
+A _score card_ is a data structure that contains the following information:
+
+- Subject: the name of the test subject,
+- Scope: the scope of all the testcases referred to in this score card,
+- Results: a mapping that maps testcase ids to results, where each result is additionally
+  equipped with validity timespan (beginning at the time of the check and expiring according to
+  the lifetime of the result).
+
+## Regulation
+
+Each standard must be decomposed into testcases. Each testcase should be "atomic" in the following two senses:
+
+- it's clear what specific part of the standard is satisfied or not satisfied;
+- the testcase can be reused for multiple versions of the standards.
+
+The latter criterion is a matter of engineering judgment, because it cannot be known in advance how a standard might evolve.
+
+Each testcase id must be prefixed by `scs-XXXX-` where `XXXX` is the document id of the standard; an exception is possible in the rare case when a testcase applies to multiple standards.
+
+A check script that can test multiple testcases should provide the option to select which testcases to run.
+
+A list of reports from a certain time frame can be merged into an aggregate score card, provided that the following conditions are satisfied:
+
+- for each testcase, the result must be taken from the most recent report containing that testcase,
+- if an additional report from the same time frame is known to exist, all its testcases must be contained in more recent reports from the list.

Standards/scs-0004-v1-achieving-certification.md

@@ -26,12 +26,6 @@ As operator, I want to obtain a certificate with the scope SCS-compatible IaaS o
 
    For public clouds, the SCS certification assessment body can take on this task provided that suitable access to test subject is supplied.
 
-   The test suite is partitioned according to resource usage; the required test intervals depend on this classification:
-
-    - _light_: at least daily,
-    - _medium_: at least weekly,
-    - _heavy_: at least monthly.
-
 3. If the desired certificate requires manual checks, then the operator MUST offer suitable documentation to the SCS certification assessment body. The operator MUST ensure that these checks are repeated once every quarter. In addition, the SCS certification assessment body reserves the right to occasionally verify documentation on premises.
 
 4. Details on the standards achieved, as well as the current state and the history of all test and check results of the past 18 months will be displayed on a public webpage (henceforth, _certificate status page_) owned by SCS.

Standards/scs-0500-v1-scopes.md

@@ -0,0 +1,14 @@
+---
+title: SCS Certificate Scopes
+type: Standard
+track: Scopes
+status: Draft
+description: |
+  Basic definitions and regulations regarding SCS certificate scopes.
+---
+
+## Definition
+
+In essence, a certificate scope is a standard that has to be fulfilled in order for a certificate to be awarded.
+It usually refers to other standards in regards to actual subject matter — what properties the subject
+has to satisfy —, and it contains regulations regarding the testing regime.

Standards/scs-0501-v1-scs-compatible-iaas.md

@@ -0,0 +1,30 @@
+---
+title: SCS-compatible IaaS
+type: Standard
+track: Scopes
+status: Deprecated
+stabilized_at: 2021-01-01
+deprecated_at: 2023-10-31
+description: |
+  The certificate scope for level SCS-compatible and layer IaaS.
+---
+
+## Introduction
+
+This is v1 of the certificate scope _SCS-compatible IaaS_.
+
+## Subject Matter
+
+The following standards are included:
+
+- OpenStack-powered Compute v2020.11
+- [scs-0100-v1: Flavor naming](https://docs.scs.community/standards/scs-0100-v1-flavor-naming)
+- [scs-0102-v1: Image metadata](https://docs.scs.community/standards/scs-0102-v1-image-metadata)
+
+## Testing Regime
+
+The following regulations apply for those certifications where regular testing is required.
+
+In general, automated tests (where applicable) shall be performed at least weekly.
+
+- Tests for OpenStack-powered Compute may be performed less frequently, but no fewer than once a year.

Standards/scs-0501-v2-scs-compatible-iaas.md

@@ -0,0 +1,39 @@
+---
+title: SCS-compatible IaaS
+type: Standard
+track: Scopes
+status: Deprecated
+stabilized_at: 2023-03-23
+deprecated_at: 2023-11-30
+replaces:
+- scs-0501-v2-scs-compatible-iaas.md
+description: |
+  The certificate scope for level SCS-compatible and layer IaaS.
+---
+
+## Introduction
+
+This is v2 of the certificate scope _SCS-compatible IaaS_.
+
+## Subject Matter
+
+Standards that were already included in v1:
+
+- [scs-0102-v1: Image metadata](https://docs.scs.community/standards/scs-0102-v1-image-metadata)
+
+Standards changed in v2:
+
+- OpenStack-powered Compute v2022.11 (instead of v2020.11)
+- [scs-0100-v2: Flavor naming](https://docs.scs.community/standards/scs-0100-v2-flavor-naming) (instead of [v1](https://docs.scs.community/standards/scs-0100-v1-flavor-naming))
+
+## Testing Regime
+
+The following regulations apply for those certifications where regular testing is required.
+
+In general, automated tests (where applicable) shall be performed at least weekly.
+
+- Tests for OpenStack-powered Compute may be performed less frequently, but no fewer than once a year.
+
+## Version history
+
+- v2 amends v1 in the way outlined under 'subject matter'.

Standards/scs-0501-v3-scs-compatible-iaas.md

@@ -0,0 +1,40 @@
+---
+title: SCS-compatible IaaS
+type: Standard
+track: Scopes
+status: Deprecated
+stabilized_at: 2023-06-15
+deprecated_at: 2024-07-31
+replaces:
+- scs-0501-v2-scs-compatible-iaas.md
+description: |
+  The certificate scope for level SCS-compatible and layer IaaS.
+---
+
+## Introduction
+
+This is v3.1 of the certificate scope _SCS-compatible IaaS_.
+
+## Subject Matter
+
+Standards that were already included in v2:
+
+- OpenStack-powered Compute v2022.11
+- [scs-0102-v1: Image metadata](https://docs.scs.community/standards/scs-0102-v1-image-metadata)
+
+Standards changed in v3.1:
+
+- [scs-0100-v3: Flavor naming (v3.1)](https://docs.scs.community/standards/scs-0100-v3-flavor-naming) (instead of v3.0)
+
+## Testing Regime
+
+The following regulations apply for those certifications where regular testing is required.
+
+In general, automated tests (where applicable) shall be performed at least weekly.
+
+- Tests for OpenStack-powered Compute may be performed less frequently, but no fewer than once a year.
+
+## Version history
+
+- Compared to v3.0, v3.1 includes v3.1 of [scs-0100-v3](https://docs.scs.community/standards/scs-0100-v3-flavor-naming) instead of v3.0.
+- Compared to v2.0, v3.0 includes v3.0 [scs-0100-v3](https://docs.scs.community/standards/scs-0100-v3-flavor-naming) instead of [scs-0100-v2](https://docs.scs.community/standards/scs-0100-v2-flavor-naming).

Standards/scs-0501-v4-scs-compatible-iaas.md

@@ -0,0 +1,42 @@
+---
+title: SCS-compatible IaaS
+type: Standard
+track: Scopes
+status: Deprecated
+stabilized_at: 2024-02-28
+deprecated_at: 2025-07-01
+replaces:
+- scs-0501-v3-scs-compatible-iaas.md
+description: |
+  The certificate scope for level SCS-compatible and layer IaaS.
+---
+
+## Introduction
+
+This is v4 of the certificate scope _SCS-compatible IaaS_.
+
+## Subject Matter
+
+Standards that were already included in v3.1:
+
+- OpenStack-powered Compute v2022.11
+- [scs-0100-v3: Flavor naming (v3.1)](https://docs.scs.community/standards/scs-0100-v3-flavor-naming)
+- [scs-0102-v1: Image metadata](https://docs.scs.community/standards/scs-0102-v1-image-metadata)
+
+Standards new to v4:
+
+- [scs-0101-v1: Entropy](https://docs.scs.community/standards/scs-0102-v1-image-metadata)
+- [scs-0103-v1: Standard flavors](https://docs.scs.community/standards/scs-0103-v1-standard-flavors)
+- [scs-0104-v1: Standard images](https://docs.scs.community/standards/scs-0104-v1-standard-images) with [spec file](https://raw.githubusercontent.com/SovereignCloudStack/standards/main/Tests/iaas/scs-0104-v1-images.yaml)
+
+## Testing Regime
+
+The following regulations apply for those certifications where regular testing is required.
+
+In general, automated tests (where applicable) shall be performed at least weekly.
+
+- Tests for OpenStack-powered Compute may be performed less frequently, but no fewer than once a year.
+
+## Version history
+
+- v4 extends v3 by including new standards as listed above.

Standards/scs-0501-v5-scs-compatible-iaas.md

@@ -0,0 +1,55 @@
+---
+title: SCS-compatible IaaS
+type: Standard
+track: Scopes
+status: Stable
+stabilized_at: 2024-12-19
+replaces:
+- scs-0501-v4-scs-compatible-iaas.md
+description: |
+  The certificate scope for level SCS-compatible and layer IaaS.
+---
+
+## Introduction
+
+This is v5.1 of the certificate scope _SCS-compatible IaaS_.
+
+## Subject Matter
+
+Standards that were already included in v4:
+
+- [scs-0128-v1: SCS end-to-end testing (formerly OpenStack-powered Compute)](https://docs.scs.community/standards/scs-0128-v1-e2e-testing)
+- [scs-0100-v3: Flavor naming (v3.1)](https://docs.scs.community/standards/scs-0100-v3-flavor-naming)
+- [scs-0101-v1: Entropy](https://docs.scs.community/standards/scs-0102-v1-image-metadata)
+- [scs-0102-v1: Image metadata](https://docs.scs.community/standards/scs-0102-v1-image-metadata)
+- [scs-0103-v1: Standard flavors](https://docs.scs.community/standards/scs-0103-v1-standard-flavors)
+
+Standards changed with v5:
+
+- [scs-0104-v1: Standard images](https://docs.scs.community/standards/scs-0104-v1-standard-images) with [new spec file](https://raw.githubusercontent.com/SovereignCloudStack/standards/main/Tests/iaas/scs-0104-v1-images-v5.yaml) instead of [former spec file](https://raw.githubusercontent.com/SovereignCloudStack/standards/main/Tests/iaas/scs-0104-v1-images.yaml)
+
+Standards new to v5:
+
+- [scs-0114-v1: Volume Types](https://docs.scs.community/standards/scs-0114-v1-volume-type-standard)
+- [scs-0115-v1: Default rules for security groups](https://docs.scs.community/standards/scs-0115-v1-default-rules-for-security-groups)
+- [scs-0116-v1: Key manager](https://docs.scs.community/standards/scs-0116-v1-key-manager-standard)
+- [scs-0117-v1: Volume backup](https://docs.scs.community/standards/scs-0117-v1-volume-backup-service)
+- [scs-0121-v1: Availability Zones](https://docs.scs.community/standards/scs-0121-v1-Availability-Zones-Standard)
+- [scs-0123-v1: Mandatory and Supported IaaS Services](https://docs.scs.community/standards/scs-0123-v1-mandatory-and-supported-IaaS-services)
+- [scs-0302-v1: Domain Manager Role](https://docs.scs.community/standards/scs-0302-v1-domain-manager-role)
+
+## Testing Regime
+
+The following regulations apply for those certifications where regular testing is required.
+
+In general, automated tests (where applicable) shall be performed at least weekly.
+
+- Tests for scs-0128-v1 may be performed less frequently, but no fewer than once a year.
+
+## Version history
+
+- v5.1 amends v5 by including the standard scs-0123-v1,
+  which was intended to be included (as witnessed by the meeting minutes),
+  but inadvertently omitted.
+- v5 extends v4 by including new standards as listed above,
+  and it changes the spec for scs-0104-v1, updating standard images.

Standards/scs-0501-w1-scs-compatible-iaas-testing.md

@@ -0,0 +1,11 @@
+---
+title: "SCS-compatible IaaS: Testing Notes"
+type: Supplement
+track: Scopes
+supplements:
+  - scs-0501-v5-scs-compatible-iaas.md
+---
+
+## Testing notes
+
+(refer to documentation of official test suite)

Standards/scs-0502-v1-scs-compatible-kaas.md

@@ -0,0 +1,29 @@
+---
+title: SCS-compatible KaaS
+type: Standard
+track: Scopes
+status: Stable
+stabilized_at: 2024-11-26
+description: |
+  The certificate scope for level SCS-compatible and layer KaaS.
+---
+
+## Introduction
+
+This is v1 of the certificate scope _SCS-compatible KaaS_.
+
+## Subject Matter
+
+- [scs-0201-v1: CNCF Kubernetes conformance](https://docs.scs.community/standards/scs-0201-v1-cncf-conformance)
+- [scs-0210-v2: Kubernetes version policy](https://docs.scs.community/standards/scs-0210-v2-k8s-version-policy)
+- [scs-0214-v2: Kubernetes node distribution and availability](https://docs.scs.community/standards/scs-0214-v2-k8s-node-distribution)
+- [scs-0219-v1: KaaS networking](https://docs.scs.community/standards/scs-0219-v1-kaas-networking)
+
+## Testing Regime
+
+The following regulations apply for those certifications where regular testing is required.
+
+In general, automated tests (where applicable) shall be performed at least weekly.
+
+- Tests for scs-0210-v2 shall be performed daily.
+- Tests for scs-0201-v1 and scs-0219-v1 may be performed less frequently, but no fewer than once a year.

Standards/scs-0502-w1-scs-compatible-kaas-testing.md

@@ -0,0 +1,11 @@
+---
+title: "SCS-compatible KaaS: Testing Notes"
+type: Supplement
+track: Scopes
+supplements:
+  - scs-0502-v1-scs-compatible-kaas.md
+---
+
+## Testing notes
+
+(refer to documentation of official test suite)