Please see our public web site and specifically the About SCS page. SCS describes a standard as well as a reference implementation of this standard.
The easiest way to get in touch with SCS is to deploy a SCS cloud virtually.
This means that you set up a SCS test installation including all the infrastructure pieces such as database, message queueing, ceph, monitoring and logging, IAM, the OpenStack core services, and (soon) the Container layer on top of an existing IaaS platform. Currently, only OpenStack is supported as IaaS under the SCS cloud (so you end up using OpenStack on top of OpenStack -- with nested virtualization enabled, this performs decently). There is no fundamental limitation -- just noone has done the porting of the terraform recipes yet to AWS, libvirt, VMware, ...
The SCS IaaS reference implementation is based on OSISM. Read on the OSISM testbed docs to learn how to get the testbed running. Please read carefully through the deployment section of the manual.
The Requirements:Cloud access subsection also lists some clouds that we have SCS running on and test regularly.
You can easily deploy the container layer on top of the testbed (or a production SCS cloud of course) checking out the code from k8s-cluster-api-provider.
A few production clouds are already based on SCS: betacloud and PlusCloud Open. More will come soon.
For PlusCloud Open, there is also a document how to get started guide for the PlusCloud Demonstrator env.
CityNetwork, Open Telekom Cloud, OVH clouds are also known to support the testbed well. (There are a few caveats with the latter two, but those are documented and no blockers.) Read above mentioned Requirements:Cloud access subsections.
The work done in SCS is supposed to be fed back upstream -- into the relevant CNCF projects, into OpenStack, into kolla-ansible, into OSISM and others. An OSISM deployment thus will bring you all the SCS greatness in the base layer. Whenever possible SCS works directly in the upstream projects. While the SCS projects tracks the efforts across the released in epics and userstories, the work on the code happens upstream - as such these repositories are usually not found in the SCS namespace.
SCS R0 has been released on 2021-07-15 and bundles the work accomplished by the community prior to the full start of the project.
See Release Notes for R0 for more information.
R1 came quickly after R0 and was the first release to ship a production ready k8s stack (with k8s cluster API), some identity federation integration and much improved preconfiguration for monitoring and logging.
See Release Notes for R1 for more information.
This release delivers vast improvements for bare metal automation and the features in the container layers.
See Release Notes for R2 for more information.
We have a 6 month release cadence -- R3 will follow in September 2022. Until then, we will provide bugfixes and security fixes for R2.
We do work towards a model where our partners can actually follow our main development branches -- right now, our CI needs a bit more coverage though to make this safe.
Please see the SCS contributor guide.
We intend to work on a conformity test suite.
Right now, we are basically relying on upstream tests -- RefStack (to perform the OpenStack trademark certification tests formerly known as DefCore) and the Kubernetes CNCF conformance tests run through sonobuoy.
We have two specific standards aligned within the SCS community (and have also sought feedback from the broader Gaia-X and OpenStack communities):
Beyond this, we have a draft document that captures our view on how SCS compatible environments should look like. This one has not yet seen sufficient review to be eligible for standardization. However, we appreciate feedback (raise issues and PRs or start discussions).
Please raise issues on github. If you can identify the affected component, raise the issue against the relevant repository in the SovereignCloudStack or OSISM space. Otherwise you can use the issues repository. Obviously we appreciate PRs even more than issues; please don't forget to sign off your contributions (see contributor guide ).
When reporting bugs, it is very useful to include some standard information typically needed to analyze:
- What state of software (SCS) were you testing? What version numbers ... ?
- How does your environment look like (hardware, operating systems, etc.)?
- What did you do?
- What did you expect? What happened instead?
- Have you done this successfully before? What changed?
- Can this be reproduced? Occasionally? Reliably? How?
- Any analysis you have done? Experiments and their results? Log files?
Please check our main web page. If you are an onboarded SCS community member, find here a link to our nextcloud (login required).
Our community interacts through our github organization, on mailing lists as well as chats matrix.org:SCS.