Agama and Probing

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

When Agama needs to Probe

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.

How Agama Probes

With the current implementation, Agama services never probe the system automatically. Clients (UI and CLI) are in charge of probing or reprobing when it is needed.

In the case of the storage service, it sets the system as dirty if iSCSI, DASD or zFCP was configured, but a reprobing is not done.

This was designed so to avoid too many probings after every action, specially when loading a profile.

Probing at Web UI Client

The web UI client explicitly does:

A complete probe after selecting a product.
A complete probe after registering a product.
A storage reprobe if the system is dirty.

Problems:

The storage settings are lost after registering a product.
The reprobe of a dirty system is only done if you visit the storage page.

Probing at CLI Client

The CLI client explicitly does:

A complete probe after selecting a product.
A complete probe after registering a product.
A storate reprobe if the system is dirty. It is done after loading iSCSI/DASD and before loading the storage section.

Problems:

The storage settings are lost after registering a product.

Proposed Solution

Clients should not take over of probing or reprobing. Requirements:

Services probe or reprobe if needed.
Clients are able to know if an action has finished. For example, the selection of the product has finished once the probing is done.
Avoid unnecessary probes. For example, if a product is selected and registered in the same call, then only a probe call is needed after doing both actions.
Avoid probe-interfering between clients. For example, with the current implementation the Web UI could raise a storage reprobing when a profile is loaded using the CLI.

Extend Manager API

The Agama manager could offer a method for applying a config. The manager calls to the respective #SetConfig methods of each service (software, storage, etc) and decides when to probe/reprobe.

For example, for selecting and registering a product, Manager#SetConfig would be called with this config:

{
  "product": {
    "id": "Tumbleweed",
    "registrationCode": "..."
  }
}

And the manager service would perform these actions:

start_progress
progress.step { product.apply_config }
progress.step do
  if (product_changed?)
    software.probe
    storage.probe
  elsif (product_registered?)
    storage.reprobe
  end
end

Clients do not need to call to individual services for applying a config. They always call to Manager#SetConfig, and the action (with progress) will be finished once the required probes are done.

joseivanlopez/agama-reprobe.md