Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Description for adjust_by_ram (#1081)
## 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](https://github.com/openSUSE/agama/blob/master/doc/storage_ui.md#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](https://github.com/yast/yast-installation/blob/master/doc/control-file.md#the-volumes-subsection), 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).
- Loading branch information
