Initially, the Agama D-Bus service was written 100% in Ruby. For many things, it relies on YaST, so it makes sense to use the same language. It was great to have something working quickly, but it also had some drawbacks. The main problem is that, as YaST is not thread-safe, we separated the service into different processes (storage, software, localization, etc.). The system became most responsive but at the cost of eating a lot of RAM.

Moving to Rust

As the project diverged from YaST, the team decided to try a different approach for the new code. We implemented some D-Bus services from scratch using Rust. Those changes had a positive impact on Agama's memory consumption. At this point, Agama implements the following services:

• Software: software installation, product registration, etc. (Ruby)
• Storage: partitioning, encryption, etc. (Ruby)
• Locale: language/keyboard/timezone handling (Rust).
• Network: basic network configuration (Rust)
• Questions: handle user interaction (Rust).
• Users: initial user creation and root authentication (Ruby).
• Manager: coordinates the rest of the services to install the system. It is Agama's conductor. (Ruby)

The goal

This project aims to (partially) port the manager and the user services to Rust. Rewriting all the code is unrealistic (at least for a Hack Week project), but the Rust code can call the Ruby/YaST part only when needed. After all, YaST implements a mechanism for that (YaST clients).

Technical details

What the manager does

The Managerservice is responsible for orchestrating the installation process. It keeps track of other the services' status and asks them to do their jobs. Its D-Bus interface contains a mixture of high-level actions (Probe, Commit, Finish) and status information (e.g., CanInstall, installation_phases, current_installation_phase, or busy_services).

YaST code in the manager

Most of the installation work is performed by the storage and the software services, including writing the security settings. However, the manager still relies partially in YaST/Ruby code:

• Copying the network configuration (see network.rb).
• Proposing/writing the proxy settings (see proxy_setup).
• Relies on YaST2::ArchFilter when reading the configuration.
• We moved ‘users’ handling to the Manager service recently.

Calls to WFM.CallFunction are only in the storage service.

What is needed

If we wanted to move this service, we might need to:

• Implement Progress and ServiceStatus interfaces in Rust.
• Extend the Rust-based clients to connect to storage and software and users. It is trivial, as we already have clients for them.
• Move the proxy and network settings to the network service we already have.
• Migrate the Ruby code to Rust:
  • Coordinate the startup, config and installation phases.
  • Listen for events from other services.