joseivanlopez

Challenges to solve with queries and hooks in storage

How to organize the model queries

In storage we have a JSON structure (model) and we need:

• To get part of the model (e.g., a specific disk).
• To get calculated information (e.g., whether a disk is the boot device).
• To modify parts of the model (e.g., add a partition to a disk).

joseivanlopez

agama-expert-partitioner.mp4

joseivanlopez

Feedback from QE

• +5 List of PR & blog that can change our test cases or more related with the UI, CLI.

• +3 Don't understand, hard to follow.

• +3 Keep the demo but with changes.

• +2 For bug resolution in Agama they would like to see where it is fixed and how. Also there are some with interest in rust that would like to see sometimes internal. But this would be on demand.

• +2 Interested on agama architecture, how some components communicate with others, that would help to understand developer's task.

• +1 Get list by email to study the topics with some day(s) on advance.

• +1 Demo not practical enough, for instance, pre/post feature was presented with an 'echo' instead of using a more real user scenario (looked theoretical).

joseivanlopez

Guided Settings VS Storage Config

Comparison between the guided settings and the storage config formats to decide whether to finally kill the guided settings.

The so called guided settings is a JSON format defined to cover the Agama storage use cases. The storage service translates the guided settings to Y2Storage settings and calculates a proposal by calling to the Y2Storage guided proposal.

The storage config is a new and more powerful JSON format introduced for auto-installation. Agama also defines its own proposal, and both the storage config and the Agama proposal are able to cover all the use cases supported by the guided settings and the Y2Storage guided proposal.

Agama is going to stop using the Y2Storage guided proposal in favor of the new Agama proposal. Note that the guided proposal was originally designed to support an small set of use cases. Independently on the client (CLI, UI, auto-install, ...), Agama will always call to its own proposal.

joseivanlopez

Changes in storage APIs

D-Bus API

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

joseivanlopez

Reevalute the storage guided settings

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": {}

joseivanlopez

Storage HTTP and D-Bus APIs

Storage proposal settings

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.

Through a D-Bus call

• 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.

joseivanlopez

Agama Auto-installation (Storage Settings)

Format specification

Storage
  disk <Disk[]>
  md <MD[]>
  lvm <VolumeGroup[]>
  bcache <BCache[]>
 nfs 

joseivanlopez

Agama Auto-installation (Storage Settings)

Format specification

Storage
  drives <Drive[]>
  volume_groups <VolumeGroup[]>
  software_raids <SoftwareRaid[]>
  bcache_devices <BCache[]>
 nfs_devices 

joseivanlopez

Agama Roadmap

Features To Implement

Architectural Changes

• Drop Cockpit dependency.
• Replace Cockpit login by own solution.
  • Check proposed solution with security team.
• Replace Cockpit translation system by own solution.