- 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:
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.
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:
This document highlights how sudo
and openssh
are configured for (open)SUSE products and points some proposed improvements.
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.
- 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.
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.
Let's start describing the main DInstaller
service, which is the central point for managing the overall installation process:
org.opensuse.DInstaller
- 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:
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.
Let's start by describing how UDisks2
organizes its API:
org.freedesktop.UDisks2
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.
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.