This document proposes a mechanism to enhance Desktop Environment (DE) selection within the Agama Software configuration. By flagging specific patterns in the product metadata, Agama can distinguish graphical environments from standard software packages, allowing the UI to present them prominently.

Currently, selecting a desktop environment requires users to find specific items within a flat list of software patterns. As a primary installation decision, this choice should be visually distinct and easily accessible. Leveraging the existing user_patterns structure allows us to categorize these choices without altering the underlying configuration schema.

System

{
  zfcp: {
    allowLunScan: true,
    controllers: [
      {
        channel: "0.0.0100",
 active: true,

org.opensuse.Agama.Storage1 /org/opensuse/Agama/Storage1 org.opensuse.Agama.Storage1 org.opensuse.Agama.Storage1.Bootloader org.opensuse.Agama.Storage1.ISCSI.Initiator

/org/opensuse/Agama/Storage1/ISCSI

/org/opensuse/Agama/Storage1/iscsi_nodes/1 org.opensuse.Agama.Storage1.ISCSI.Node

What to do when applying a config:

• if the product is unknown (invalid, missing):
  • add product issue
  • keeps the current config and proposal (if any)
  • report 400

PUT: the config must indicate a valid product.

api.ts
/api/system

queries.ts

hooks/system.ts
hooks/l10n/system.ts
hooks/storage/system.ts

agama
    CONTRIBUTING.md
    PACKAGING.md
    LICENSE
    PULL_REQUEST_TEMPLATE.md
    README.md
 SECURITY.md

org.opensuse.Agama.Storage1                     interface -                     -
.Finish                                         method    -                     -
.GetConfig                                      method    -                     -
.GetConfigModel                                 method    -                     -
.Install method - -

The new API of Agama offers an end-point to retrieve the status of the installation (GET /status).

The status contains the installation state and the progress of each scope in a single JSON file.

The installation can be in one of the following states:

The new API is designed around 3 main concepts: system, config and proposal.

• system: represents the current status of the running system.
• config: represents the configuration for installing the target system.
• proposal: represents what is going to be done in the target system.

The config contains elements that can modify the system, the proposal or both. For example, the dasd config changes the system, and the storage config changes the proposal. In other cases like network, the config can affect to both system and proposal.

This document analyzes when Agama probes the system and what problems the current approach has, and proposes a possible solution.

• After selecting a product: a complete probe (software, storage, etc).
• After registering a product: a complete probe but keeping some settings (a.k.a., reprobe). For example, storage settings should not be lost.
• After editing iSCSI, DASD, zFCP: a storage reprobe.