One platform — standardized, built and operated by many.
One platform — standardized, built and operated by many.
The Sovereign Cloud Stack project is developed continuously. Continuous testing ensures that the latest code remains usable most of the time. To better serve our cloud provider partners that have limited appetite for change and are not very tolerant against occasional breakage, we publish releases.
Every 6 months, there is a new major release – this is the time where major improvements get integrated and where we move to the latest proven versions of the many upstream projects we work on and contribute to. This is also where we occasionally have to introduce breaking changes – obviously something that we don’t do easily and that we carefully communicate by deprecation announcements well ahead of time.
In between those major releases we publish several minor releases that bring incremental improvements as well as bug and security fixes.
The technologies used in SCS allow for very flexible configuration. This is great! On the flip side, platforms composed of a very similar set of technologies can look very different to users and applications, resulting in extra effort to get accustomed to each platform and sometimes significant effort to automate workloads, especially if these want to achieve high availability. The SCS project aims to provide a high degree of portability between SCS-compatible platforms by defining standards. These are built on top of existing upstream standards and define further aspects of platform behavior that application developers and operators need.
The SCS software release does obviously implement all the SCS Standards by default; however the standards can also be fulfilled by independent implementations. The release cycle of standards is not tightly coupled with the software release. This would only be needed if a new implementation is required to meet new standards. While this can happen, it is an exception.
The SCS project is currently finalizing a new set of standard scopes: The version 4 of our SCS-compatible standards on the IaaS layer and the first version of SCS standards on the Container (Kubernetes) layer. We encourage software developers, DevOps Teams and Providers alike to look at the ongoing work, provide feedback and contribute to the standardization process.
With this out of the way, let’s turn back to our upcoming release.
While our CI pipelines do nightly verification of the built software, we encourage our cloud service provider partners to do additional testing, especially ahead of a release. There are always issues that are specific to the setups and configurations of our partners that can not always be found in our nightly pipelines. In the end, upgrading test and staging platforms ahead of a release also provides our partners with the experience and confidence in the release and the upgrade process, so we can not only produce high quality releases, but also have our partners upgrade their production platforms quickly.
After discussion with our partners, for R6, we have determined to create a more formal release candidate cadence and a more formalized test results collection than we used to, reflecting the increasing size of our provider ecosystem as well as the increasing size of our larger partners’ environments.
Extending our previous announcement of the R6 release, we have come up with the following schedule for release candidates:
| R6 RC | ETA | notes |
|---|---|---|
| RC0 | 2024-02-07 | aka 7.0.0a |
| RC1 | 2024-02-21 | |
| RC2 | 2024-03-06 | |
| RC3 | 2024-03-13 | may not be needed and be skipped |
| RCx | 2024-03-1y | if needed in order to retest |
| final | 2024-03-20 | aka 7.0.0 |
Note that with the first release candidate (RC0), the large features have all been completed, been integrated and must be working. We still work on improving documentation, increasing test coverage and of course on fixing bugs. We may grant a small number of exceptions to this rule for so-called late features to be complete after RC0 (typically with RC1) and we will make these transparent to our testers to avoid wasting effort.
The focus for RC0 is to test the upgrade on the IaaS layer, where OSISM has integrated the new OpenStack version 2023.2 (aka Bobcat). We have some work pending in the IAM area and on the container layer where we have the exciting new technology with Cluster Stacks. Both can be tested already, but will receive a few more changes until RC1. One of the areas of R6 where we may not achieve 100% completion is to cover all cases where Kubernetes Clusters are migrated from the old cluster-API based K8s-as-a-Service solution (KaaS v1) to the new cluster stacks (also built on top of cluster-API). Expect improvements here until later release candidates and read the release notes to understand which scenarios are covered and which ones may not be covered by full automation yet when we finalize R6.
The high level goals for R6 are documented in the R6 outcomes blog article. A more fine-grained list of features is collected in the R6 release notes that will get more and more complete over the next weeks.
The development teams are very focused to respond quickly to issues reported against our release candidates. We’d like to ask testers to open issues in github against the relevant repositories as usual. To facilitate quick and more interactive communication, we also invite testers and developers to join the SCS | Release Engineering and Testing R6 Matrix room to stay atop of announcements, reports and responses that come in.