Use italics for *SCS-compatible* and the other levels.

Signed-off-by: Kurt Garloff <[email protected]>

Author: garloff

standards/certification/cert-levels.md

@@ -14,12 +14,12 @@ operators of the infrastructure what compliance rules they fulfill.
 The SCS project however has defined certification levels for levels two,
 three and four in the sovereignty taxonomy.
 
-| Digital Sovereignty level         | SCS certification       |
-|-----------------------------------|-------------------------|
-| 1: Data Sov'ty / Legal compliance | (Refer to ENISA/Gaia-X) |
-| 2: Provider switching / Tech Compatiiblity | SCS-compatible |
-| 3: Ability to shape technology    | SCS-open                |
-| 4: Transparency & SKills for Operations    | SCS-sovereign  |
+| Digital Sovereignty level         | SCS certification         |
+|-----------------------------------|---------------------------|
+| 1: Data Sov'ty / Legal compliance | (Refer to ENISA/Gaia-X)   |
+| 2: Provider switching / Tech Compatiiblity | *SCS-compatible* |
+| 3: Ability to shape technology    | *SCS-open*                |
+| 4: Transparency & SKills for Operations    | *SCS-sovereign*  |
 
 As of September 2024, the *SCS-compatible* certification level is defined
 and used; the details for the higher levels are still being worked on.

standards/certification/getting-scs-compatible-certified.md

@@ -17,7 +17,7 @@ The SCS certification process typically consists of a few simple steps:
 3. The operator must be a member ("shaper" or "advisor" level) of the Forum SCS-Standards in the
    OSB Alliance (a non-profit) and pay the respective membership fees. Alternatively fees can
    be paid without becoming a member.
-4. The cloud can be listed on the SCS pages as SCS-compatible with a compatibility status that is
+4. The cloud can be listed on the SCS pages as *SCS-compatible* with a compatibility status that is
    updated on a daily basis. SCS then tests the infrastructure on a daily basis.
 
 ## Self-testing and technical adjustments
@@ -32,14 +32,14 @@ The best approach to get your cloud into compliance is by installing the
 test suite locally. Have a look at the
 [example](/standards/certification/test-and-adapt-example).
 
-A description how SCS-compatible IaaS compliance can be achieved on environments that use different
+A description how *SCS-compatible IaaS* compliance can be achieved on environments that use different
 OpenStack implementations is written up in a blog article
 [Cost of making an OpenStack Cluster SCS compliant](https://scs.community/2024/05/13/cost-of-making-an-openstack-cluster-scs-compliant/).
 
 ## Declarations
 
-For the SCS-compatible IaaS v5 standard, the providers must -- if they implement availability zones
-at all (which is optional) -- guarantee certain levels of independence for these. This can not
+For the SCS-compatible IaaS v5 standard, the providers must — if they implement availability zones
+at all (which is optional) — guarantee certain levels of independence for these. This can not
 be fully tested by an automated test. The process thus envisions that providers must create some
 documentation on the physical infrastructure and how it maps to availability zones and declare that
 this documentation reflects the truth. SCS will review the docs and judge whether they meet the
@@ -55,8 +55,7 @@ process.
 Members of the OSBA can become also member of the Forum SCS-Standards for an additional membership
 fee, providing the financial resources for the Forum to do its work. Membership in the OSBA is
 open to any organization that supports the goals of the OSBA.
-Alternatively, a certification fee can be paid without any membership; the fee corresponds to the
-lower tier membership fee.
+Alternatively, a certification fee can be paid without any membership.
 
 ## Getting listed and tested
 
@@ -88,7 +87,7 @@ which exposes information on the performance and error rate of each cloud.
 This provides some transparency on the state of the clouds by constantly running
 scenario tests against them and is tremendously helpful for both the cloud operations
 teams and their customers. Strictly speaking, it is *not* a requirement for the
-SCS-compatible certification, just best practice. It will be part of an
+*SCS-compatible* certification, just best practice. It will be part of an
 SCS-sovereign certification though, where transparency on operational aspects
 is included.
 
@@ -99,7 +98,7 @@ will enjoy the nightly tests. These might fail for a number of reasons:
 
 * There is a new version of the SCS standards in effect and you need to adjust things.
 * Your cloud was unreachable or otherwise had intermittent issues.
-* You have done changes to your cloud that break SCS-compatible compliance.
+* You have done changes to your cloud that break *SCS-compatible* compliance.
 * The test automation engine (github actions / zuul) is in trouble.
 * The tests have a bug.
 

standards/certification/test-and-adapt-example.md

@@ -14,6 +14,7 @@ e.g. by issuing a command like `openstack --os-cloud=MYCLOUD catalog list` or
 `KUBECONFIG=~/.kube/MYCLUSTER.yaml kubectl get nodes -o wide`.
 
 Let's do a run against a sample environment:
+
 ```bash
 garloff@framekurt(//):/casa/src/SCS/standards/Tests [1]$ ./scs-compliance-check.py -V v4 -s CIAB -a os_cloud=ciab-test scs-compatible-iaas.yaml
 INFO: module opc-v2022.11 missing checks or test cases
@@ -56,7 +57,7 @@ CIAB SCS-compatible IaaS v4 (effective):
       > Must fulfill all requirements of https://docs.scs.community/standards/scs-0104-v1-standard-images
 ```
 
-So we run the SCS-compatible IaaS tests defined in `scs-compatible-iaas.yaml` in version `v4`; without option `-V`,
+So we run the *SCS-compatible IaaS* tests defined in `scs-compatible-iaas.yaml` in version `v4`; without option `-V`,
 the latest effective version would have been used. We further define the cloud to be named `CIAB` (short for
 Cloud-in-a-Box) in the report. And we set the parameter `os_cloud` to `ciab-test`. This references the
 name of the cloud as configured in OpenStack `clouds.yaml` and `secure.yaml` which contain the configuration
@@ -68,6 +69,7 @@ Let's have a look at the results:
   We also receive 13 warnings for not having recommended flavors, we can ignore them for now.
 * On the images side, the mandatory image `Ubuntu 22.04` is not registered.
 * The end result is that we passed three tests and failed to comply with two specs:
+
 ```yaml
     - standard-flavors-check:
       > Must fulfill all requirements of https://docs.scs.community/standards/scs-0103-v1-standard-flavors
@@ -81,6 +83,7 @@ the entropy test and the image metadata test.
 ## Address issues
 
 To fix the failures, we will thus need to:
+
 * Add properties to the two flavors where they are missing.
 * Register the `Ubuntu 22.04` image (with the appropriate metadata).
 
@@ -101,7 +104,9 @@ INFO: Flavor SCS-4V-16: SET scs:name-v1=SCS-4V:16
 INFO: Flavor SCS-4V-16: SET scs:name-v2=SCS-4V-16
 INFO: Processed 15 flavors, 6 changes
 ```
+
 and as this is a OSISM-based SCS system, we can on the manager just run the image manager:
+
 ```shell
 dragon@manager:~$ osism manage images --cloud admin --filter "Ubuntu 22.04"
 2024-09-23 13:21:43 | INFO     | Processing image 'Ubuntu 22.04 (20240705)'
@@ -142,14 +147,14 @@ dragon@manager:~$ osism manage images --cloud admin --filter "Ubuntu 22.04"
 dragon@manager:~$
 ```
 
-A description how SCS-compatible IaaS compliance can be achieved on environments that use different
+A description how *SCS-compatible IaaS* compliance can be achieved on environments that use different
 OpenStack implementations is written up in a blog article
 [Cost of making an OpenStack Cluster SCS compliant](https://scs.community/de/2024/05/13/cost-of-making-an-openstack-cluster-scs-compliant/).
 
-
 ## Rerun tests
 
 We now succeed:
+
 ```shell
 garloff@framekurt(//):/casa/src/SCS/standards/Tests [130]$ ./scs-compliance-check.py -V v4 -s CIAB -a os_cloud=ciab-test scs-compatible-iaas.yaml
 INFO: module opc-v2022.11 missing checks or test cases