org.opensuse.Agama.Storage1
#ProductDefinition - JSON {transactional, volumes, encryptionMethods}
#Probe - probes the system (*without calculating a proposal?)
#SetConfig - set JSON config ({storage}, {legacyAutoyastStorage})
#GetConfig - get JSON config
The storage section of the Agama settings has two different parts: the specification of the devices (e.g., drives, volumeGroups, etc) and the so called guided settings:
"storage": {
"drives": [],
"volumeGroups": [],
"mdRaids": [],
"guided": {}
There are different ways for indicating the storage proposal settings: through a D-Bus call, from a JSON config file, through a HTTP call (JSON), and from a YAML product file.
- The
#Calculate
D-Bus method is called with the expected D-Bus data (a{sv}
). - The storage service generates a
ProposalSettings
ruby object from the D-Bus data and calculates the proposal.
Agama uses yast2-packager and yast2-pkg-bindings API for selecting patterns/packages and solving dependencies, calling to the libzypp C++ library under the hood.
Sometimes there are conflicts with the selected packages/patterns. In that cases, the zypp resolver fails and reports a list of problems. In that cases, the YaST Packager UI shows the poblems to the user, allowing to select a solution for each problem.
Agama needs something similar to YaST Packager in order to notify and fix the solver problems. This document analyzes how to bring that feature to Agama.
This document analyses different approaches for registering a product and exposes some possible solutions for implementing registration in Agama.
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?
Manager
Probe(product)
Software#SelectProduct
Storage#Probe ?
Storage#Calculate
Software#Probe
Storage
Probe