Merge branch 'main' into 526-refine-cve-check-in-scs-0210-v2-test-script

Author: piobig2871

Drafts/README.md

@@ -1,5 +1,11 @@
-# Design-Docs
+# Drafts Archive
 
-Design Documents, Architecture etc. for SCS and related technology
+## Deprecation Notice
 
-Here we collect docs that cover overarching SCS topics or topics that otherwise do not belong to an existing repository.
+> [!CAUTION]
+> Please do not create new files in this folder!
+
+The contents of this folder are for archival purposes only. New drafts belong
+in the [`../Standards/`](https://github.com/SovereignCloudStack/standards/tree/main/Standards)
+folder instead and adhere to the lifecycle described in
+[scs-0001-v1-sovereign-cloud-standards](https://github.com/SovereignCloudStack/standards/blob/main/Standards/scs-0001-v1-sovereign-cloud-standards.md).

Standards/scs-0100-w1-flavor-naming-implementation-testing.md

@@ -2,7 +2,7 @@
 title: "SCS Flavor Naming Standard: Implementation and Testing Notes"
 type: Supplement
 track: IaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0100-v1-flavor-naming.md
   - scs-0100-v2-flavor-naming.md

Standards/scs-0101-w1-entropy-implementation-testing.md

@@ -2,7 +2,7 @@
 title: "SCS Entropy: Implementation and Testing Notes"
 type: Supplement
 track: IaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0101-v1-entropy.md
 ---

Standards/scs-0102-w1-image-metadata-implementation-testing.md

@@ -2,7 +2,7 @@
 title: "SCS Image Metadata: Implementation and Testing Notes"
 type: Supplement
 track: IaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0102-v1-image-metadata.md
 ---

Standards/scs-0104-w1-standard-images-implementation.md

@@ -2,7 +2,7 @@
 title: "SCS Standard Images: Implementation Notes"
 type: Supplement
 track: IaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0104-v1-standard-images.md
 ---

Standards/scs-0116-w1-key-manager-implementation-testing.md

@@ -2,7 +2,7 @@
 title: "SCS Key Manager Standard: Implementation and Testing Notes"
 type: Supplement
 track: IaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0116-v1-key-manager-standard.md
 ---

Standards/scs-0118-w1-example-impacts-of-failure-scenarios.md

@@ -2,7 +2,7 @@
 title: "SCS Taxonomy of Failsafe Levels: Examples of Failure Cases and their impact on IaaS and KaaS resources"
 type: Supplement
 track: IaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0118-v1-taxonomy-of-failsafe-levels.md
 ---

Standards/scs-0123-v1-mandatory-and-supported-IaaS-services.md

@@ -1,7 +1,8 @@
 ---
 title: Mandatory and Supported IaaS Services
 type: Standard
-status: Draft
+status: Stable
+stabilized_at: 2024-11-20
 track: IaaS
 ---
 
@@ -40,7 +41,7 @@ The following IaaS APIs MUST be present in SCS-compliant IaaS deployments and co
 :::caution
 
 S3 API implementations may differ in certain offered features.
-CSPs must publicly describe, which implementation they use in their deployment.
+CSPs must publicly describe the endpoints of their S3 solutions and which implementations they use in their deployment.
 Users should always research whether a needed feature is supported in the offered implementation.
 
 :::
@@ -56,20 +57,19 @@ The following IaaS APIs MAY be present in SCS-compliant IaaS deployment, e.g. im
 | Supported API | corresponding OpenStack Service | description |
 |-----|-----|-----|
 | **bare-metal** | Ironic | Bare Metal provisioning service |
-| **billing** | Cloudkitty | Rating/Billing service |
+| **billing** | CloudKitty | Rating/Billing service |
 | **dns** | Designate | DNS service |
 | **ha** | Masakari | Instances High Availability service |
 | **key-manager** | Barbican | Key Manager service |
 | **object-store** | Swift | Object Store with different possible backends |
 | **orchestration** | Heat | Orchestration service |
 | **shared-file-systems** | Manila | Shared File Systems service |
-| **telemetry** | Ceilometer | Telemetry service |
-| **time-series-databse** | Gnocchi | Time Series Database service |
+| **time-series-database** | Gnocchi | Time Series Database service |
 
 ## Unsupported IaaS APIs
 
 All other OpenStack services, whose APIs are not mentioned in the mandatory or supported lists will not be tested for their compatibility and conformance in SCS clouds by the SCS community.
-Those services MAY be integrated into IaaS deployments by a Cloud Service Provider on their own responsibility but the SCS will not assume they are present and potential issues that occur during deployment or usage have to be handled by the CSP on their own accord.
+Those services MAY be integrated into IaaS deployments by a Cloud Service Provider on their own responsibility but SCS will not assume they are present and potential issues that occur during deployment or usage have to be handled by the CSP on their own accord.
 The SCS standard offers no guarantees for compatibility or reliability of services categorized as unsupported.
 
 ## Related Documents
@@ -78,5 +78,5 @@ The SCS standard offers no guarantees for compatibility or reliability of servic
 
 ## Conformance Tests
 
-The presence of the mandatory OpenStack APIs will be tested in [this test-script](https://github.com/SovereignCloudStack/standards/blob/mandatory-and-supported-IaaS-services/Tests/iaas/mandatory-services/mandatory-iaas-services.py).
-The test will further check, whether the object store endpoint is compatible to s3.
+The presence of the mandatory OpenStack APIs will be tested in [this test-script](https://github.com/SovereignCloudStack/standards/blob/main/Tests/iaas/mandatory-services/mandatory-iaas-services.py)
+The test will further check whether the object-store endpoint is compatible to s3.

Standards/scs-0211-w1-kaas-default-storage-class-implementation-testing.md

@@ -2,7 +2,7 @@
 title: "SCS KaaS default storage class: Implementation and Testing Notes"
 type: Supplement
 track: KaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0211-v1-kaas-default-storage-class.md
 ---

Standards/scs-0214-v1-k8s-node-distribution.md

@@ -80,42 +80,6 @@ If the standard is used by a provider, the following decisions are binding and v
   can also be scaled vertically first before scaling horizontally.
 - Worker node distribution MUST be indicated to the user through some kind of labeling
   in order to enable (anti)-affinity for workloads over "failure zones".
-- To provide metadata about the node distribution, which also enables testing of this standard,
-  providers MUST label their K8s nodes with the labels listed below.
-  - `topology.kubernetes.io/zone`
-
-    Corresponds with the label described in [K8s labels documentation][k8s-labels-docs].
-    It provides a logical zone of failure on the side of the provider, e.g. a server rack
-    in the same electrical circuit or multiple machines bound to the internet through a
-    singular network structure. How this is defined exactly is up to the plans of the provider.
-    The field gets autopopulated most of the time by either the kubelet or external mechanisms
-    like the cloud controller.
-
-  - `topology.kubernetes.io/region`
-
-    Corresponds with the label described in [K8s labels documentation][k8s-labels-docs].
-    It describes the combination of one or more failure zones into a region or domain, therefore
-    showing a larger entity of logical failure zone. An example for this could be a building
-    containing racks that are put into such a zone, since they're all prone to failure, if e.g.
-    the power for the building is cut. How this is defined exactly is also up to the provider.
-    The field gets autopopulated most of the time by either the kubelet or external mechanisms
-    like the cloud controller.
-
-  - `topology.scs.community/host-id`
-
-    This is an SCS-specific label; it MUST contain the hostID of the physical machine running
-    the hypervisor (NOT: the hostID of a virtual machine). Here, the hostID is an arbitrary identifier,
-    which need not contain the actual hostname, but it should nonetheless be unique to the host.
-    This helps identify the distribution over underlying physical machines,
-    which would be masked if VM hostIDs were used.
-
-## Conformance Tests
-
-The script `k8s-node-distribution-check.py` checks the nodes available with a user-provided
-kubeconfig file. It then determines based on the labels `kubernetes.io/hostname`, `topology.kubernetes.io/zone`,
-`topology.kubernetes.io/region` and `node-role.kubernetes.io/control-plane`, if a distribution
-of the available nodes is present. If this isn't the case, the script produces an error.
-If also produces warnings and informational outputs, if e.g. labels don't seem to be set.
 
 [k8s-ha]: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/
 [k8s-large-clusters]: https://kubernetes.io/docs/setup/best-practices/cluster-large/