ALP Prototype is Evolving, Proof of Concept Expected in Fall
The Adaptable Linux Platform (ALP) is switching from the UNIX-style centered, influenced structure of previous operating systems to a more workload and application-centric design. A flexible and secure platform with advancing concepts, as seen in both MicroOS and SLE Micro, along with the incorporation of other components, is evolving. This platform is designed to easily build, deploy and manage applications regardless of hardware or environment.
Separating the hardware enablement in a Host OS and a (containerized) Application Layer provides an immutable platform for workloads and workload runtime environments.
While the Adaptable Linux Platform proof of concept is not provided with desktop, the addition of desktop to ALP will be done in following releases:
ALP is Built and tested in public instances of OBS and openQA.
The prototype consists of an immutable image and an orchestrator providing application-layer features.
OpenSUSE MicroOS will serve as a base operating system for the container orchestrator.
Container orchestrators, so far, k3s. Podman is also available for non-k8s workload.
As a prototype, MicroOS and k3s will be used for each layer; the roadmap shows there will be more container orchestrators with a final version that could include a variation of MicroOS instead of the official one.
This prototype includes the following characteristics and principles:
Full disk encryption
The encryption on ALP is specifically designed to manage encrypted devices that do not have any human interaction. For instance, patch management, which is ideal for edge architecture, it is done by using Trusted Platform Module (TPM) using cryptographic keys
Self-healing and self-management
ALP leverages self-healing and self-management features from a containerized perspective. Both these features can identify and perform tasks considering not only the OS but the containerized layer; no OS tasks will be disruptive to the workload.
Environments must be flexible and agile states, which sometimes causes multiple dependencies if you are working with Python, Java, Node, or any other programming language. This could result in a messy environment – dealing with incompatibilities between these dependencies, packages, libraries or tools.
ALP addressed that with Base Container Images (BCI) to create independent stacks that make the developer’s life easier.
To manage multi-stack environments coexistence, ALP is developed by these principles:
- Ease of installation: Users can create, manage, update and delete stacks independently without affecting other developing environments.
- Security checks via k8s webhook/plugin: Using the capabilities provided by the orchestrator, the code can be followed to prevent any potential attacker interfering through the usage of sigstore/cosign.
ALP is designed to be flexible and agile to provide users the stack they need to develop and manage their platforms and workloads.
The Proof of Concept
Proof of concepts should have the following considerations:
- Time frame: As per current development, Proof of Concept (PoC) should be considered for a short-time frame (3 months).
- Adding value: The content must include the specific value added by ALP with a clear differentiation between ALP and SLE.
- Coherent fashion: Delivering the PoC in a way that can be shared with partners and some other relevant actors, it should also include market research people.
- Baseline: ALP should be considered the baseline for the PoC, avoiding disaggregation between the layers inside. To be clear, there is no SLE + k3s, but ALP as a base concept and can be built on top of ALP.
- Qualifying out scenarios: ALP is a prototype of a concept that is not for all scenarios; the PoC does not need to work for all scenarios or platforms.
OpenSUSE ALP Community update https://news.opensuse.org/tag/adaptable-linux-platform
We do publish weekly updates on Community Work Group: https://en.opensuse.org/openSUSE:ALP/Workgroups/Community