New storage proposal settings

[ancorgs]

Problem

The information about the products offered for installation is provided to Agama by means of a config file (e.g., /etc/agama.yaml). That config file contains an storage section which indicates the volumes (file systems) to create in the target system. Right now, this storage section is basically the same as the section for the YaST config file. But the storage use cases for Agama are only a subset of all the possibities YaST offers. Because of that, some YaST storage options simply do not make sense for Agama, but the config file still has to indicate them in order to make YaST to work properly.

We need an easier way to specify the storage options for the Agama use cases. The very YaST specific options should not be exposed in the Agama config file.

• https://trello.com/c/drW2FI0q/3388-8-agama-storage-proposal-settings
• https://gist.github.com/ancorgs/afaf1e8b9279b05f25ffe6a7bb1efefc
• https://gist.github.com/joseivanlopez/ce50025c2703c7b5ce04b8e0853c0c18

Solution

The storage settings for Agama config are redefined.

See example

  storage:
    lvm: true
    encryption:
      method: luks2
      pbkd_function: pbkdf2
    space_policy: delete
    volumes:
      - "/"
    volume_templates:
      - mount_path: "/"
        mount_options:
          - default
          - data=ordered
        filesystem: btrfs
        btrfs:
          snapshots: true
          read_only: true
          default_subvolume: "@"
          subvolumes:
            - path: root
            - path: home
            - path: opt
            - path: srv
            - path: var
              copy_on_write: false
        size:
          auto: false
          min: 5 GiB
          max: unlimited
        outline:
          required: true
          filesystems:
            - btrfs
            - ext4
            - xfs
          auto_size:
            base_min: 10 GiB
            base_max: 100 GiB
            snapshots_increment: 200%
            adjust_by_ram: false
            min_fallback_for:
              - "/home"
            max_fallback_for:
              - "/home"
          snapshots_configurable: false

The main changes are in the volumes section. Now, volumes only contains the mount points of the volumes to create:

volumes:
  - "/"
  - "swap"

And there is a new volume_templates section. This new section contains a template for each volume. A template consists on a set of default values and a volume outline. The outline represents some specific information about the volume which cannot be changed, for example, the possible file system types for the volume.

    volume_templates:
      - mount_path: "/"
        filesystem: btrfs
        size:
          auto: false
          min: 5 GiB
          max: unlimited
        outline:
          required: true
          filesystems:
            - btrfs
            - ext4
            - xfs

There is also a generic volume template to be used for a new arbitrary volume. The generic volume template does not indicate a mount path.

    volume_templates:
      - filesystem: xfs
        size:
          auto: false
          min: 1 GiB
          max: unlimited
        outline:
          required: false
          filesystems:
            - btrfs
            - ext4
            - xfs

Volumes and storage proposal

Agama initially calculates the storage proposal trying to create all the volumes indicated in the volumes section of the control file. A new proposal can be triggered from D-Bus calling to #Calculate method from org.opensuse.Agama.Storage1.Proposal.Calculator interface. #Calculate receives the settings to use for the new proposal.

Proposal settings conversions

In Agama a proposal is calculated by calling to Agama::Storage::Proposal#calculate, which receives a Agama::Storage::ProposalSettings object. The proposal settings object needs to be generated from two different sources: the agama config file for the initial proposal and from the information provided from D-Bus for calculating a new proposal:

• The class Agama::Storage::ProposalSettingsReader generates the proposal settings from the config file.
• There is a conversion class Agama::DBus::Storage::ProposalSettingsConversion::FromDBus to generate the proposal settings from the D-Bus information.

And then, Agama delegates the real computation of the proposal to Y2Storage. For that, the proposal settings are converted to the Y2Storage format thanks to the class Agama::Storage::ProposalSettingsConversion::ToY2Storage.

There are two more conversions for the proposal settings:

• Agama::DBus::Storage::ProposalSettingsConversion::ToDBus: generates a D-Bus representation of the proposal settings, useful for the D-Bus interfaces providing information about the proposal.
• Agama::Storage::ProposalSettingsConversion::FromY2Storage: generates proposal settings from the Y2Storage format. This is useful to rebuild the proposal settings once Y2Storage has finished to calculate the proposal.

Testing

• New unit tests.
• Tested manually.

[jreidinger]

nothing critical, just typos and one possible code improvement