Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend scs-0003: more context and process (resolves issues/#343) #329

Merged
merged 4 commits into from
Sep 5, 2023
Merged

Extend scs-0003: more context and process (resolves issues/#343) #329

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
693b96f
Extend scs-0003: more context and process (issues/#343)
mbuechse Aug 10, 2023
6c69567
More consistent language around certificate vs certification
mbuechse Aug 10, 2023
63ba5bf
Drop misleading sentence from scs-0001
mbuechse Aug 14, 2023
4088cd7
Included intended length of grace period
mbuechse Aug 14, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 0 additions & 2 deletions Standards/scs-0001-v1-sovereign-cloud-standards.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -223,8 +223,6 @@ Changes to the documents are gated through pull requests.

Once the document is deemed ready for production use,
its `status` is changed to `Stable`.
Once the next SCS release happens,
the document is officially part of the SCS standard.

After stabilization,
changes to the document which may render existing implementations non-conformant
Expand Down
74 changes: 61 additions & 13 deletions Standards/scs-0003-v1-sovereign-cloud-standards-yaml.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,34 +10,62 @@ track: Global
The [Sovereign Cloud Stack (SCS)](https://scs.community) provides standards for a range of cloud infrastructure types.
It strives for interoperable and sovereign cloud offerings which can be deployed and used by a wide range of organizations and individuals.

With a growing number of documents and certification levels for Sovereign Cloud Stack, it is becoming increasingly difficult to keep track
of all stable, obsoleted as well as all upcoming standards. This decision record describes how we use technically describe
certification levels and the mandatory standards therein.
SCS plans to offer six types of certificates, which are sorted into two dimensions:

1. _certification level_, of which there are three:
- SCS-compatible
- SCS-open
- SCS-sovereign
2. _cloud layer_, of which there are two:
- infastructure as a service (IaaS)
- Kubernetes as a service (KaaS)
mbuechse marked this conversation as resolved.
Show resolved Hide resolved

So, for instance, a certificate can be of type _SCS-compatible IaaS_ or _SCS-sovereign KaaS_.

Each type of certificate amounts to a set of standards that have to be fulfilled by the cloud service in question in order for a certificate to be issued.
In addition, a certificate of a certain type may only be issued if some other certificate is already held.
Case in point: the certification levels are meant to be seen as a progression, where the upper levels build on the lower ones, and
the certificate for "SCS-open IaaS" will only be issued if a certificate for "SCS-compatible IaaS" is already held.
We say that the latter certificate is a _prerequisite_ of the former.

Naturally, as the state of the art progresses, so do our certificates. We keep track of the changes by means of versioning.
That is to say that each certificate type can come in several versions, each one of them having its distinct timespan when it is in effect.
For instance, we might have

- SCS-compatible IaaS v1, effective 2021-01-01 through 2023-10-31
- SCS-compatible IaaS v2, effective 2023-03-23 through 2023-11-30

and so on (but usually, we aim to keep at most two versions in effect, with an overlap of 4 to 6 weeks).

This decision record describes two main points:

1. How we denote our certificate types by means of a YAML file.
2. Our process for constructing and progressing the certificate types.

## Motivation

This decision record has three main objectives:
This decision record establishes a mechanism (by means of the YAML file) with the following three main objectives:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this of type Procedural and not of Decision Record?

Suggested change
This decision record establishes a mechanism (by means of the YAML file) with the following three main objectives:
This standard establishes a mechanism (by means of the YAML file) with the following three main objectives:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The verbiage in question didn't stem from me. Anyway, following your argumentation, we should change "decision record" into "procedural", right? However, I suppose "decision record" could be construed as a kind of general term (a superset) that includes Standards, Procedurals, and any other document. From this point of view, every standard is a decision record, but not every decision record is a standard. If we expressly designate a document as "decision record" in the header, then this mostly means that it doesn't fit into any of the subcategories. Just one way of looking at it.


- to provide an overview of the mandatory standards for the different SCS certification levels
- to make the lifecycle of certification levels traceable
- to provide an overview of the mandatory standards for the different SCS certificate types
- to make the lifecycle of certificate types traceable
- to provide a machine-readable document for further processing (e.g. for a compliance tool suite or continuous integration).

## Overview of mandatory SCS standards
### Overview of mandatory SCS standards

Digging through a repository of draft, stable, replaced and rejected standards becomes increasingly challenging with a growing number
documents and decision records. A central document that lists all mandatory standards to acquire a certain certification level can
documents and decision records. A central document that lists all mandatory standards to acquire a certificate of a certain type can
resolve this issue. It provides clarity for providers as well as users and helps to understand the value
proposition of SCS.

### Lifecycle of certification levels
### Lifecycle of certificate types

Standards and therefore certifications will evolve over time. To provide transparency and traceability for the lifecycle of SCS certification
levels, the whole history of our certifications should be recorded. Pre-notification of changes to our certification levels allows
Standards and therefore certifications will evolve over time. To provide transparency and traceability for the lifecycle of SCS certificate
types, the whole history of our certifications should be recorded. Pre-notification of changes to our certificate types allows
users to adapt their environments or deployment automation to the new standards in advance.

### Machine-readability for further processing

By providing a machine-readable document, we can generate web-friendly overviews of our certification levels as well as create a tool suite
By providing a machine-readable document, we can generate web-friendly overviews of our certificate types as well as create a tool suite
that checks environments against all described standards.

## SCS Certification YAML
Expand Down Expand Up @@ -102,6 +130,9 @@ can be certified against, unless the version is already obsoleted (the point is
This means that more than one version may be allowable at a certain point in time. Tooling should default
to use the newest allowable version (the one with the most recent `stabilized_at` date) then.

Note: We intend to keep only one version in effect, except for a grace period of 4 to 6 weeks, when two versions
are effective at the same time.

### Standards

Every list of standards consists of several standards that – altogether – define the particular layer standard in the given version.
Expand Down Expand Up @@ -141,7 +172,7 @@ iaas:
args: -v
- executable: image-md-check2.py
condition: optional
- version: v4 # This is the upcoming standard with a given target date. No further changes should be done to this set of standards
- version: v4 # This is the upcoming version with a given target date. No further changes should be done to this set of standards
stabilized_at: 2022-04-01
standards:
- name: ....
Expand All @@ -161,6 +192,23 @@ kaas:
- ...
```

## Process

The lifecycle any version of any type of certificate goes through the following phases:
Draft, Stable, and Deprecated.

```mermaid
graph TD
B[Draft] -->|Pull Request| D[Stable]
D -->|Pull Request| F[Deprecated]
```

Note that one pull request can affect multiple versions, but each pull request has to affect
at most one layer.

Each pull request is to be voted upon in the corresponding team meeting. The vote has to be
on the pull request only, i.e., it may not affect any other pull request or issue.

## Design Considerations

### File format
Expand Down