Status message

A Eclipse stratOS Creation Review has been created for this proposal.

Eclipse stratOS

Friday, July 25, 2025 - 03:01 by Ignacio Lacalle
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Community Review
Background

Eclipse stratOS inherits from a part of the results of the Horizon Europe project aerOS.

Scope

Eclipse stratOS provides a Meta Operating System that works across the entire computing spectrum, from IoT devices and edge systems to the cloud. It creates a single environment where you can deploy and manage containerized workloads across different systems and organizations, based on your specific needs.

Accessible through both a user interface and an API, Eclipse stratOS brings together several key features into one platform. These include access control, performance comparison, distributed computing, continuous monitoring, and automated processes at the edge.

Description

In the ongoing quest to develop a comprehensive Meta-OS for the continuum, the landscape is marked by existing concepts and frameworks aimed at unifying edge, cloud, and IoT resources.

Compatibility with diverse container management frameworks

In a computing world where virtualization of workloads is imperative, some companies still base on Docker management, while others have shifted to cloud-native environments, mostly relying on Kubernetes-only setups. Eclipse stratOS, however, stands out by leveraging existing concepts to significantly extend the current state-of-the-art architecture. It advances orchestration and management capabilities beyond what is currently available, offering a more flexible, robust, scalable, and efficient solution for the modern Cloud-Edge-IoT landscape. It offers the capacity to execute loads in both environments, and opens up customization for future incorporations (e.g., containerd, Wasm-based).

Seem centralized, act distributed 

Eclipse stratOS overcomes the impression of vendor-agnosticity. Using a single interface, all resources are presented the same way for the user. They can be monitored and manipulated albeit residing in different networks, be owned by different companies or having disparate characteristics. Nonetheless, Eclipse stratOS avoids centralization: the access to the information is ubiquitous and the orchestration decisions are taken in a decentralized manner. Thanks to balancing algorithms, the requests for workload commissioning (and other key processes) are handled in different spots avoiding single point of failure effects.

Standard-based communication and data management

The Meta-OS relies on using de-facto standard communication technologies, such as HTTP REST APIs, OpenAPI documentation, solid data formats such as NGSI-LD and tunnelling based on Fully-Qualified-Domain-Names for required networking (employing Wireguard VPNs). Also, due to inheriting from a research project, it aligns with impactful on-going initiatives, such as the TF3 Architecture from EUCEI.

What does Eclipse stratOS provide?

It provides a series of components that are installed over a baseline infrastructure to be provided by the adopter (typically Kubernetes clusters, virtual machines, native systems or physical machines). 

Federation of domains

Infrastructure Elements (IEs) are the fundamental computing units Eclipse stratOS, providing a unified runtime environment. A group of IEs forms a domain, the smallest administrative entity, sharing core services. Domains connect to form a Eclipse stratOS continuum, supporting a federated orchestration model facilitated by the Context Broker Orion-LD which implements NGSI-LD interface. This structure ensures peer-to-peer collaboration among domains, enabling autonomous, decentralized decision-making and fine-grained resource control. 

As the Meta-OS builds on such concepts of Domains and Infrastructure Elements, it presents differences in the components to be installed based on the topology (that is decided by the IT administrator of the adopter entity).

Deployment of containerized workloads

Eclipse stratOS introduces a two-layer orchestration model separating decision-making from execution. The High-Level Orchestrator (HLO) -a custom Python-based framework that employs Redpanda as messaging bus- acts as the decision engine, using global resource awareness to optimize workload placement across domains. It is formed of various modules, namely HLO Frontend, HLO Data Aggregator, HLO Allocator, HLO engine and HLO Local Allocation Manager. The Low-Level Orchestrator (LLO), which materializes in Go-based Kubernetes operators- handles local enforcement, translating HLO decisions into actionable commands on specific resources. This hierarchical design ensures scalability and adaptability without disrupting other domains.

Continuous observability of computing elements

To unify diverse and distributed resources, Eclipse stratOS uses a Smart Data Model from project aerOS to abstract and pool them for dynamic workload execution. It gathers real-time data on resource capabilities and availability using Prometheus or customized scripts running on all Infrastructure Elements. This comprehensive view enables the Meta-OS to make efficient placement decisions and support proactive workload migration.

Unified management portal

Eclipse stratOS is accessed via a web-based modern GUI that connects with the Meta-OS backend. It allows observing the computing resources and the deployed services, as well as to commission workloads (specifying the requirements) but also to compare the performance of such elements against relevant (edge, IoT) benchmarks. 

Move decision and intelligence to the edge

Nodes are no longer passive elements that take orders and push monitoring/logging data. In Eclipse stratOS, those are (depending on their capacities) able to trigger local orchestration notifications (e.g., to offload if saturated), scale horizontally, detect anomalies on data or on their behaviour, and to adapt the sampling frequency to certain circumstances.

Trustworthiness in the continuum

Eclipse stratOS integrates cybersecurity services for robust authentication, authorization, and access control, ensuring secure access to domain resources through role-based policies and validated identity registries (using LDAP). Its trust management framework assesses the reliability of Infrastructure Elements via a Trust Agent and Trust Manager, using metrics like behavior, health, and reputation. Trust and reputation are key, with mechanisms to ensure message immutability and trust-based resource selection (via the usage of IOTA Tangle). Security is handled holistically, combining centralized IAM (Keycloak, KrakenD) with encrypted communications (TLS, VPN) and fine-grained data access control. 

In addition, it includes the option of using Shapley weights to reinforce explainability of compatible ML models used over the Meta-OS.

Custom functions definition and deployments

Eclipse stratOS embeds a customized version of OpenFaaS to allow the execution of one-shot, serverless applications on demand. Once installed (typically, in the most cloud-liked infrastructure of the continuum), the adopter may code and upload their own applications based on pre-defined templates, which could asynchronously trigger process such as ETA, data curation or statistics visualization in natively-equipped Grafana.

Why Here?

We believe that converting part of the results of the project aerOS into an Eclipse Foundation project will help enhance the usage/adoption community, as well as increase the exploitation capabilities beyond our research project.

Future Work

Here are some of the future features to be added to Eclipse stratOS:

  • Including further rules in the self-orchestrator living in every Infrastructure Element.
  • Adding a more robust AI-based spot selection in the orchestration of workloads.
  • Polishing of the installation process.
  • Enhance of the configuration options for the services (add persistence, configuration files...) in the service orchestration system
  • Create new LLOs (e.g. containerd)
Project Scheduling

First release: September 2025

Second release: October 2025

Third release: December 2025

Committers
Przemyslaw Holda (This committer does not have an Eclipse Account)
Andreu Belsa (This committer does not have an Eclipse Account)
Jon Egaña (This committer does not have an Eclipse Account)
Pedro Romaña (This committer does not have an Eclipse Account)
Óscar López (This committer does not have an Eclipse Account)
José Luis Eguiguren (This committer does not have an Eclipse Account)
Alain Manso (This committer does not have an Eclipse Account)
Miguel Ángel Urrutia (This committer does not have an Eclipse Account)
Zofia Wrona (This committer does not have an Eclipse Account)
Giorgios Petihakis (This committer does not have an Eclipse Account)
Interested Parties

UPV
NCSRD
S21Sec
INFOLYSIS
CloudFerro
PRODEVELOP
DSTECH
InQBit
FOGUS
IBSPAN
CBT
 

 

 

Initial Contribution

The code to be released will be structured in several repos tackling the differenct functionalities included.

It will consist in a mix of codebase (mostly Python and Go) altogether with Helm charts and Dockerfiles for deploying inherited images in distributed virtualized environments (based on containerised microservices). Each of these repos will include their own license, which will fluctuate between Apache2.0, MIT License and the Unlicense.  Copyright is held by every code developer and file producer, which individuals will have an account in ECLIPSE.

There will be dependencies with third-party libraries including (but not limited to): FIWARE Orion-LD, MetalLB, Redpanda, Wireguard, Cilium, Suricata, OpenFaaS, Kubernetes, K8s Operators, among others. A more comprehensive list can be provided later.

Source Repository Type