Sovereign Cloud Stack

Eine Plattform — standardisiert, entwickelt und betrieben von Vielen.

R3 is before R4

Felix Kronlage-Dammers, Kurt Garloff 4. November 2022

Looking towards Release 4

We’ve just released the Release 3 and with that we immediately started our R4 cycle. Of course there are certain topics that we carry over from R3, especially since we work in a very iterative way, these turnovers mark a good spot to actually look at what we want to achieve with the next release cycle. While the majority of planning is done in our team meetings, Kurt, Christian and Felix prepared some initial work. For that we looked at the funding proposal, the groundwork for our funding by the BMWK, and matched that with the outcomes we’ve accomplished so far. Likewise we looked at the currently running tenders as well the ones we’re planning to kick off over the period of the next four months, since those tenders will play into items we work on for R4.

Features, functionality and what they offer to SCS Operators and Users are the heart of development and the level on which we often discuss in the planning sessions. Features as part of user stories come together in epics. When we look at SCS and the releases, we don’t just want to “throw a bunch of features over the fence”. We want to enable operators of cloud computing infrastructure, we want to provide building blocks for digital sovereignty for operators to provide innovative offers to their customers. The outcomes for our stakeholders, primarily the operators, is what we focus on when describing our goals for R4.

SCS is comprised of three pillars: Standards, Reference Implementation and Open Operations. The outcomes for Release 4 are, obviously, aligned along those pillars.

SCS is standardized

One of the big rocks for Release 4 will be bringing our Cluster standardization forward. However our standardization efforts are comprised of many efforts – we need to standardize the parameters that the cluster consumers can choose, the way how these are fed to the service to create and manage the k8s clusters and last not least the properties of the resulting clusters. The foundational work for this is the current effort to have a formalized process of documenting these standard as well as our (design) decisions.

SCS is federated

While there were efforts done during the R2 and R3 cycles to work towards federated environments, as also shown during the last GAIA-X hackathon there will be lots of activity on federation during the Release 4 cycle. With a fantastic workshop with members of The SIG (Special Interest Group) IAM as well as further members of our community we kicked this off in the first week of the R4 cycle.

SCS is continuously built and tested

The R3 cycle has - once again ;) - shown how important a very good continuous integration is. With SCS we want to enable operators to keep their environments constantly up to date with confidence. The fact that two of our operators were able to directly upgrade to Release 3 shows that we’re on the right track.

SCS is understandable

One of the areas where we’ve not advanced as much as we wanted is to lower the entry barrier to SCS and the reference implementation. However if we talk about “SCS is understandable” this shall not be reduced to our reference implementation. Our standards need to be easily understood as well, since this will lead to much better adoption. SCS being understandable is more than just mere documentation. There could be no better timing for our new colleague, Max Wolfs, to have joined the SCS team as our Knowledge Management Engineer.

SCS enables Operators with an excellent toolbox

For this to be viable an excellent toolbox is needed. Ranging from the OpenStack Image Manager, our effort to provide a status page application to the Health Monitor. The OpenStack Image Manager is the way to assure that a cloud, based on the IaaS reference implementation, carries the mandated images. Plans are to move the OpenStack Image Manager to a fully-fledged OpenStack Swiss Army Knife.

SCS helps to jump-start the Open Operations movement

The need to share knowledge to operate complex infrastructure technology goes way beyond Sovereign Cloud Stack. We want to help creating a broader movement that further develops the practices of collecting, sharing and exchanging operational experience.

Über die Autoren

Felix Kronlage-Dammers
Felix has been building (open source) IT Infrastructure since the late 90s. Between then and now felix was part of various open source development communities (from DarwinPorts, OpenDarwin to OpenBSD and nowadays the Sovereign Cloud Stack). His interests range from monitoring and observability over infrastructure-as-code to building and scaling communities and companies. He has been part of the extended board of the OSBA for the last six years and describes himself as an unix/open source nerd. If not working or spending time with his family, he is usually found on a road bike.
Kurt Garloff
CTO Sovereign Cloud Stack @ Open Source Business Alliance
While working on Physics as student and researcher in Dortmund, Wuppertal and Eindhoven, Kurt started to work with and on Linux, with first patches to the SCSI layer in the mid 90s. He has spent his post-university life in Open Source, as kernel engineer, leader of SUSE Labs (kernel, compiler, X11, security), and engineering and business leadership at SUSE. Since 2011 he has been working on Open Source cloud software, at Deutsche Telekom, as Freelancer, at T-Systems (as chief architect for the OTC) and also has been serving on the Open Infra Foundation's board. Since 2019 he has been pushing the Sovereign Cloud Stack idea which resulted in a publically funded project that he now technically leads. He still loves to occasionally write code (mostly python these days) or at least test out code from the colleagues and project. He spends his free time with his family or with running and playing table tennis.