Eclipse BlueChi is a systemd service controller intended for multi-node environments with a predefined number of nodes, and with a focus on highly regulated ecosystems such as those requiring functional safety. Potential use cases can be found in domains such as transportation, where services need to be controlled across different edge devices and where traditional orchestration tools are not compliant with regulatory requirements.
Eclipse BlueChi relies on systemd and its D-Bus API, which it extends for multi-node use case.
Eclipse BlueChi can also be used to control systemd services for containerized applications using Podman and its ability to generate systemd service configuration to run a container via quadlet.
The background for this project is described in detail in this blog post: https://www.redhat.com/en/blog/introducing-hirte-deterministic-multi-node-service-controller
Eclipse BlueChi is a simple extension to systemd that allows management of services across multiple nodes. It relies on systemd services as an abstraction layer, thus being agnostic to how the process is run by systemd ("classic" application or containerized application, or anything else…).
Eclipse BlueChi also provides a mechanism by which a service can declare to have dependencies running on other nodes, allowing it to leverage systemd to do the dependency resolution.
It does not aim at being an overall system managing the state of the entire system across the different nodes. That system (that we name “state manager”) is envisioned to work with Eclipse BlueChi but not to be Eclipse BlueChi.
Eclipse BlueChi is built around three components:
- The hirte service, which is the primary controller that runs on the primary node
- The hirte-agent services, which run on each managed node and are the agents that talk locally to systemd to instruct systemd to act on services
- The hirtectl command line, which is used by administrators to test, debug and manually manage services across nodes
Eclipse BlueChi is meant to be used in conjunction with a state manager (a program or person) that knows the desired state of the systems. This design choice has a few consequences:
- Eclipse BlueChi does not know the desired final state of the systems; it only knows how to transition between states, such as how to start, stop or restart a service on one or more nodes
- Eclipse BlueChi monitors and reports changes in the services that are running and alerts the state manager when a service stops or when the connection to a node is lost, but hirte itself does not act on these notifications
- Eclipse BlueChi does not handle the initial setup of the system; the system boots into a desired state and hirte handles the transitions from this state
The state manager program integrates with hirte over D-Bus. The state manager tells hirte to perform actions or to receive the outcome of actions. Eclipse BlueChi monitors services and nodes via D-Bus and reports state changes back to the state manager. Administrators can use the hirtectl interface to avoid interacting directly with hirte via D-Bus.
GPLv2 with pieces under BSD-3, LGPLv2.1 and MIT
No known legal issues
Eclipse SDV is emerging as the center of gravity for open source software-defined vehicle development, as separate from traditional ECU-based automotive computing. As this solution addresses specific needs illuminated by the software being developed for this use case, we felt that hirte would be of great interest and use to the community, and that hirte itself would also benefit from contributions and use by other interested parties in this space.
In addition, Eclipse Foundation holistically provides the basis for a deeply value-driven open source community, which resonates very strongly with Red Hat’s corporate values and with open source best practices.
Finally, while hirte was developed within the context of the CentOS Automotive Special Interest Group, we feel that it will be useful and interesting to other edge-related use cases beyond automotive. Because Eclipse Foundation encourages cross-project communication, we feel it is the best place to host the project for maximum visibility and collaboration.
Most of the core of hirte is currently implemented. There are some features remaining that can be found in: https://github.com/containers/hirte/issues. Hirte leverages the milestones feature of github to try to assign features to releases: https://github.com/containers/hirte/milestones but we have to admit that we tend to prefer a "release early, release often" scheme over releasing when all the tickets in a milestone have been addressed. So tickets assigned to one milestone may end up being moved to the next if a feature sufficiently large lands and is deemed important enough for the team to make a release.
A python library is being developed to allow python users and developers to interact with the hirte subsystem. There is some interest in adding additional features to hirtectl to match the functionality of systemd’s systemctl command.
An initial contribution can be made at any time. The project is currently building daily using github’s CI/CD and is incorporated into other projects, including the CentOS Automotive Stream Distribution.
Red Hat, General Motors, ETAS (Ansgar Linwedel).
The Eclipse SDV ecosystem.
Eclipse BlueChi is already a public project available at: https://github.com/containers/hirte/. It has been developed by developers at Red Hat (https://github.com/containers/hirte/graphs/contributors) with one contribution from someone not working at Red Hat.
The main part of the project is located in the src folder, where one can find the code for the agent, for the CLI (client), for the manager, for the proxy as well as the code shared between the different elements. The LICENSES folder includes a copy of all the licenses present in the source code. The source of the documentation of the project is located under the doc folder and the documentation itself can be found at: https://hirte.readthedocs.io/en/latest/. The code contains unit and integration tests that can be found in the tests folder.
Eclipse BlueChi is already packaged and available publicly in Fedora, EPEL and CentOS Automotive Stream Distribution. The code is split into three packages: hirte (which contains the manager), hirte-agent (which contains the agent) and hirte-client (which contains the CLI).
- Log in to post comments