Agama and AutoYaST

The AutoYaST schema to specify the storage setup is far from ideal and presents some structural problems. Although Agama uses its own storage schema, an Agama profile can contain a special legacyAutoyastStorage section which is a 1:1 representation of the XML AutoYaST profile.

Implementation considerations for the AutoYaST specification

In principle, implementing the legacy AutoYaST module is as simple as converting the corresponding section of the profile into a Y2Storage::PartitioningSection object and use Y2Storage::AutoInstProposal to calculate the result.

But there are some special cases in which AutoYaST fallbacks to read some settings from the YaST settings or to use some YaST mechanisms. Those cases should be taken into account during the implementation.

For example, AutoYaST relies on the traditional YaST proposal settings when "auto" is used to specify the size of a partition or to determine the default list of subvolumes when Btrfs is used. See also the sections "Automatic Partitioning" and "Guided Partitioning" at the AutoYaST documentation for situations in which AutoYaST uses the standard YaST GuidedProposal as fallback.

Problems with the AutoYaST storage schema

This section explains some of the problems that caused the AutoYaST schema (or an hypothetical compatible one) to be discarded as the main schema for Agama.

Everything is a Drive or a Partition section

This could seem a minor detail, but it has several implications:

A <type> property is required to indicated the type of device (RAID, LVM, etc).
Some properties could be meaningless for the selected type.
Having a <partitions> section for describing logical volumes is weird.

<partitioning config:type="list">
  <drive>
    <type config:type="symbol">CT_LVM</type>
    <disklabel>gpt</disklabel> <!-- It does not make sense for a volume group -->
    <partitions config:type="list"> <!-- It really means logical volumes -->
      <partition>
        <partition_id>131</partition_id> <!-- It does not make sense for a logical volume -->
      </partition>
    </partitions>
  </drive>
</partitioning>

Directly formatting devices is hammered

A <partitions> section is still needed for directly formatting a device, which shows the abuse of the schema.

<partitioning config:type="list">
  <drive>
    <disklabel>none</disklabel>
    <partitions config:type="list">
      <partition>
        <filesystem config:type="symbol">btrfs</filesystem>
      </partition>
    </partitions>
  </drive>
</partitioning>

Selecting devices is difficult and limited

The AutoYaST schema allows selecting specific devices by using the <skip_list> property. This forces to use inverse logic when looking for a device. For example, if you want to select a disk bigger than 1 GiB, then you have to skip the smaller disks:

<partitioning config:type="list">
  <drive>
    <skip_list config:type="list">
      <!-- skip devices that are smaller than 1GB -->
      <listentry>
        <skip_key>size_k</skip_key>
        <skip_value>1048576</skip_value>
        <skip_if_less_than config:type="boolean">true</skip_if_less_than>
      </listentry>
    </skip_list>
  </drive>
</partitioning>

The partitions to remove are selected by means of the <use> property, which is very limited. It only allows removing everything, nothing, specific partition numbers or linux partitions.

<partitioning config:type="list">
  <drive>
    <device>/dev/sdc</device>
    <use>2</use> <!-- Removes the partition number 2 -->
    <partitions config:type="list">
      ...
    </partitions>
  </drive>
</partitioning>

The property <partition_nr> is used for reusing a partition. Again, this option is very limited, allowing selecting a partition only by its number.

<partitioning config:type="list">
  <drive>
    <device>/dev/sdc</device>
    <partitions config:type="list">
      <partition>
        <partition_nr>1</partition_nr> <!-- Reuse the partition number 1 -->
      </partition>
    </partitions>
  </drive>
</partitioning>

Note that you could indicate the same partition number for deleting (<use>) and for reusing (<partition_nr>).

Devices are created in a indirect way

For creating new LVM volume groups, RAIDS, etc, it is necessary to indicate which devices to use as logical volumes or as RAID members. In AutoYaST, the partitions have to indicate the device they are going to be used by.

<partitioning config:type="list">
  <drive>
    <device>/dev/sda</device>
    <partitions config:type="list">
      <partition>
        <raid_name>/dev/md/0</raid_name> <!-- Indicate what device is going to use it -->
      </partition>
    </partitions>
  </drive>
  <drive>
    <device>/dev/sdb</device>
    <partitions config:type="list">
      <partition>
        <raid_name>/dev/md/0</raid_name>
      </partition>
    </partitions>
  </drive>
  <drive>
    <device>/dev/md/0</device>
  </drive>
</partitioning>

It would be more natural to indicate the used devices directly in the RAID or logical volume drive.

Actions to make space must be very explicit

There is no way to specify optional actions to be performed on the existing devices, like "resize a given partition as much as needed to make space for the new ones" or "delete a partition only if necessary" or "grow the existing partition to use the rest of the available space".

MD RAIDs and LVM Volume Groups must be described exhaustively

To get a volume group on top of partitions distributed across several disks, the profile must specify the partitions that will serve as physical volumes on each disk, including exact sizes. That implies that, in order to get fully precise logical volumes, the creator of the profile must have some knowledge about the overhead in size introduced by each partition and the corresponding physical volume header and also about all the rounding introduced by the LVM logical volumes.

Something similar happens with MD RAIDs that sit on top of partitions. The sizes are specified at partition level even if the usable size of the resulting MD RAID may not obvious.

Of course, the problem accumulates when defining an LVM volume group on top of an MD RAID that sits on top of some partitions. All the sizes may match (including all possible overheads and rounding) or the result will contain either wasted or surplus space.

The New Agama storage schema

Agama offers its own storage schema (using a storage section instead of the mentioned legacyAutoyastStorage) which is more semantic, comprehensive and flexible than the AutoYaST one.

The new schema allows:

To clearly distinguish between different types of devices and their properties.
To perform more advanced searches for disks, partitions, etc.
To indicate deleting and resizing on demand.

The Agama schema is used by a new Agama specific proposal. This decouples the algorithm from the AutoYaST one, making much easier to support new use cases and avoiding backward compatibility with fringe AutoYaST scenarios. It also supports some features that are not available in the AutoYaST proposal like deleting or resizing partitions on demand.

7.1 KiB Raw Permalink Blame History