joseivanlopez

Agama Issues

• Services will have a list of issues.
• Services will refresh the list of issues after some actions (e.g., probing, calculating a proposal, etc).
• Each issue indicates its source (e.g., system, config, commit).
• Clients will check the list of issues for each service.
• There is no need of a validation interface. The issues have a severity.

D-Bus Implementation

joseivanlopez

Redesigning D-Bus API For Agama

This document exposes some weak points with the current D-Bus API for Agama (former D-Installer) and proposes some possible improvements. Most of the issues addressed here are related to how deliver and retrieve information of each service and from the overall process, for example, the status of a service, the progress report, the general installation status, etc.

Current API

Let's start describing the main DInstaller service, which is the central point for managing the overall installation process:

org.opensuse.DInstaller

joseivanlopez

Agama Storage Reprobing

Desired solution

• Devices are activated (e.g., iSCSI, DASD, etc) and no probing is done yet.
• After activation, current proposal is invalidated if any of its candidate devices is not available anymore (requires soft-probing).
• A probing has to be requested in order to see the new devices.
• The previous proposal is lost and a new one has to be requested.

In the UI, all this implies:

joseivanlopez

D-Bus API for iSCSI

D-Installer is going to add support for connecting to iSCSI targets. For that, the current D-Installer D-Bus API has to be extended. This document analyzes how other projects (i.e., UDisks) do it and proposes some possible approaches. At the end of the document there is a section for addressing some current issues with the status of the services, which would also imply some API re-design.

UDisks2 Objects and Interfaces

Let's start by describing how UDisks2 organizes its API:

org.freedesktop.UDisks2

joseivanlopez

D-Installer CLI

D-Installer already shipped an initial CLI prototype for managing and driving the installation process. Note that such a CLI was created as a proof of concept, and its current API needs some refactoring. This document is intended to discuss how the new CLI should look like, what patterns to follow, etc.

CLI Guidelines

There already are guidelines for creating modern CLI applications. For example clig.dev defines a guide that is agnostic about programming languages and tooling in general, and it can be perfectly used as reference for D-Installer CLI.

Command name

joseivanlopez

joseivanlopez

WSL Product Selection and Registration

Now WSLg supports GUI applications. In order to avoid having different images for each SLE product (e.g., SLES, SLED, etc), the firstboot should provide a way to decide what product to use.

In this document we describe different options to achieve that.

• https://jira.suse.com/browse/PED-1380
• https://jira.suse.com/browse/PM-3439

Use cases

joseivanlopez

Cockpit on ALP

This document is intended to summarize what is working and what requires some attention in cockpit running on ALP for both transactional and non-transactional systems.

Detected issues are marked in bold.

Overview

• Health: ok
• Usage: ok (in general)

joseivanlopez

Option A

Manager
    #policies
    #enabled_policies
    #disabled_policies
    #enable_policy(policy)
    #disable_policy(policy)
 #enabled_rules(policy)

joseivanlopez

Installation Phases

The installation process follows a set of phases. Only the main service (DInstaller::Manager) knowns the information about the current installation phase. The rest of services will act as utility services without any knowledge about the whole installation process.

A client (e.g., web UI) will ask to the main service for the current phase of the installation.

Phases

In principle, the installation will follow 3 possible phases: Startup, Config and Install.