Skip to content

Commit

Permalink
Remove term "SCS compliance" from the ADR
Browse files Browse the repository at this point in the history
This commit drops occurrences of the term "SCS compliance" from the ADR.
This term should be discussed and standardized (defined) first
by the SCS community.

Signed-off-by: Matej Feder <[email protected]>
  • Loading branch information
matofeder committed Feb 16, 2023
1 parent 079b162 commit 6a174bc
Showing 1 changed file with 10 additions and 11 deletions.
21 changes: 10 additions & 11 deletions Decisions/scs-XXXX-v1-requirements-for-container-registry.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,21 +20,20 @@ users and CSPs.

# Motivation

This proposal is motivated by use cases in which CSPs would like to offer SCP-compliant
This proposal is motivated by use cases in which CSPs would like to offer
private container registries to their customers. The specific use cases should be
discussed, but overall CSP could offer a private container registry as a service or
CSP could offer a recipe for customers to deploy the private registry themselves
utilizing CSP infrastructure. In both cases, the private container registry should
be SCS-compliant and should fulfill a set of needed requirements e.g. for security and
privacy.
utilizing CSP infrastructure. In both cases, the private container registry
should fulfill a set of needed requirements e.g. for security and privacy.

The idea and purpose of this document is to specify what requirements a
specific technical container registry implementation (i.e. software solution) needs to
fulfill in the context of SCS.

Another purpose is the selection of an appropriate container registry
implementation that meets all defined requirements to make architectural
decision on what implementation is fully SCS-compliant and will be used by the SCS.
decision on what implementation will be used by the SCS.

# Design considerations

Expand All @@ -58,8 +57,8 @@ Note: Keep in mind that at the time of writing this document, we’ve made our b
## OSS health check

This section evaluates the health of the open-source projects that were selected from
the currently available solutions. SCS-compliant software must fulfill all OSS health
checks defined by the [OSS-Health](https://github.com/SovereignCloudStack/standards/blob/main/Design-Docs/OSS-Health.md)
the currently available solutions. The container registry software must fulfill all OSS
health checks defined by the [OSS-Health](https://github.com/SovereignCloudStack/standards/blob/main/Design-Docs/OSS-Health.md)
document. The main health checks are:
- Four Opens (code is fully open source, community is open and diverse, development
process is open, design process is open)
Expand Down Expand Up @@ -197,8 +196,8 @@ Refer to the list of evaluated projects with their classified categories and com

This section provides an overview of the feature set of open source container registry
implementations (which passed the OSS health stage above) and map out requirements
(and nice-to-haves) against it. SCS-compliant software must be robust enough, to be able
to operate under heavy load (e.g. high availability (HA) mode, federation, etc.) and
(and nice-to-haves) against it. The container registry software must be robust enough,
to be able to operate under heavy load (e.g. high availability (HA) mode, federation, etc.) and
the crucial feature is security.
We defined a set of required features that the container registry implementation must
have and also a set of desirable (nice to have) features are defined and evaluated here.
Expand Down Expand Up @@ -278,7 +277,7 @@ Keppel, Portus, Kraken, etc.) has been carefully evaluated based on the two main
factors: the open-source health and range of supported features.

The open-source software health is crucial and container registry implementation should
pass it to be SCS-compliant. The OSS health check evaluates several important metrics
pass it. The OSS health check evaluates several important metrics
of an open source software like whether the code/community/development/design is
fully open or whether the project's maturity, security, and activity are on the desired
level. This check also evaluates the lock-in risk due to possible single points of
Expand Down Expand Up @@ -352,7 +351,7 @@ integration of p2p solutions like Kraken and Dragonfly.
# Decision

Based on the research and conclusion above we've decided to use the **Harbor** project
as an SCS-compliant container registry implementation.
as a container registry implementation for the SCS ecosystem.


<!-- Frequently used references -->
Expand Down

0 comments on commit 6a174bc

Please sign in to comment.