Description for adjust_by_ram

[ancorgs]

Problem

In Agama a volume can have automatic sizes based on one or several of the following reasons:

• Snapshots
• Fallbacks from other volumes (eg. "/" max size can exist or not based on the existence of "/home")
• Size of the RAM

The three are already implemented and working. But the third one lacks the corresponding explanations.

No information icon in the "auto" label	Incomplete sentence in the form

Solution

This pull request introduces the missing messages, so now the proper information is displayed both in the table of volumes and in the form.

The "auto" label	The form

The message is "as good as it gets" for the time being. The plan is to add the size of the RAM to it, but for that we need to improve the Agama API as reflected at
https://trello.com/c/suiA6MzZ/354-agama-api-for-system-information-like-ram-size

Additionally, this pull request enables adjust_by_ram for swap at the Tumbleweed product, to raise awareness and get feedback.

About the approach

We can already foresee people asking "where is my 'Enlarge to RAM Size for Suspend' checkbox"? So let's explain how the approach has changed. That approach, not only for swap but for so-called volumes in general, is explained in the section "Automatic Size Limits" of the document describing the storage UI.

In the traditional YaST storage proposal users has no direct way to specify the size of the partitions/LVs being created. The product specifies the size limits. If those limits cannot be known beforehand because they depend on other factors, the product configuration specify those factors. All that is explained at the YaST configuration document, which details the usage of fallback_for_*, snapshots_size, snapshots_percentage and adjust_by_ram.

Since users cannot adjust the sizes directly, the mentioned checkbox "Enlarge to RAM Size for Suspend" was introduced as a way to influence them. But to be honest, it has been controversial from the beginning since determining the proper size for the swap partition is an extremely complex topic.

It's also worth noticing that swap is not the only volume that could use that setting. Some products may adapt the size of other file-systems based on the RAM size. For example, defining a bigger partition for "/" or "/var" in order to allocate the kernel dumps generated by kdump.

As explained in the document mentioned above: "so far the adaptation consists in ensuring all the sizes are, at least, as big as the RAM. In the future, an extra adjust_by_ram_mode option could be added to allow other approaches".

In Agama the philosophy of volumes is different in general. Users can always adapt any size limit if they know what they are doing. The product still provide sensible defaults (fixed or automatic) but the users can always tweak those sizes. The case of "enlarge to RAM size" fits quite well in that new philosophy. Users don't need to know the technical details about how swap and RAM sizes correlate (and suspend-to-ram is NOT the only reason, the topic goes way further). They can just trust the automatic proposal that will be good enough for most people or adjust the size limits if they know what they are doing.

If needed, we can extend the possibilities for the product in the future (for example, a configuration option to only observe RAM in case of physical machine, using fixed size limits for virtual machines).

Testing

Tested manually (see screenshots).

[coveralls]

coverage: 74.145% (-0.02%) from 74.167%
when pulling 133076d on ancorgs:adjust_by_ram_hint
into 49dfd5b on openSUSE:master.

[dgdavid]

LGTM