joseivanlopez

Agama And Product Registation

This document analyses different approaches for registering a product and exposes some possible solutions for implementing registration in Agama.

Installation Vs Registration (Chicken-egg Problem)

An installer like Agama (or YaST) needs to know any repository from which to get the packages of the product to install.

SUSE repositories are only known after registering a product, but SUSEConnect CLI (i.e., the official tool for registering) cannot register a product unless it is already installed. So, how is the system actually installed by YaST?

joseivanlopez

Agama Storage Overview

Storage

2 devices used for the installation:

512 GiB Micron 100 SATA vda 1 TiB Assus 2239 vdb

joseivanlopez

Manager
  Probe(product)
    Software#SelectProduct
    Storage#Probe ?
    Storage#Calculate
    Software#Probe

Storage
 Probe

joseivanlopez

Update products and release

Update Agama config

• Update products in service/etc/agama.yml
• Use correct repositories for each product
• Make sure the required patterns are available in the repos
• Set the correct base_product name. To get it, check the internal name:

joseivanlopez

Agama Storage Settings

This document proposes a possible solution for defining the new storage settings for Agama. The result is based on this other document, which uses the VolumeTemplate concept for representing the settings of a volume coming from the control file.

Why yet another proposal for settings

The definition of the storage settings in the control file, and its transcription to Agama code by means of the VolumeTemplate approach seem to have some flaws.

One thing to consider is the repetition of fields. A VolumeTemplate and the resulting Volumes created from them have some fields in common. Repetition is not a problem per se, but it does not sound totally correct. Moreover, it seems that a VolumeTemplate is used for several things at the same time:

joseivanlopez

Current API

# busctl --address unix:path=/run/agama/bus tree org.opensuse.Agama.Storage1
└─/org
  └─/org/opensuse
    └─/org/opensuse/Agama
      └─/org/opensuse/Agama/Storage1
 └─/org/opensuse/Agama/Storage1/zfcp_luns

joseivanlopez

SUSE sudo and openssh

This document highlights how sudo and openssh are configured for (open)SUSE products and points some proposed improvements.

sudo

Currently sudo is configured to always ask for the root password, and this could have some problems:

• The behavior might be unexpected:
• sudo typically asks for the current user password.

joseivanlopez

Agama Storage D-Bus API

This document analyzes how UDisks2 D-Bus API looks and what approach to follow for exposing devicegraph details in the Agama API.

UDisks2

Partitions

/dev/sda (Micron1)

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