Replies: 3 comments 5 replies
-
Idea 1. Moving one step from the current UI“Installation device” box becomes “Installation devices” and allows to add:
Every new device will receive an alias that can be always auto-calculated (based on the device name) but that the user can override. Adding a new device to the list only adds that device, not necessarily the underlying ones (eg. a new LVM that will automatically create partitions on sda and sdb does not add those disks to the list). We may need to reconsider some aspects of the filesystems box (currently titled "Partitions and filesystems"). Each entry can represent either:
Using a device (instead of creating a new partition/lv) is probably something that should be more integrated into the edition of the filesystem, since it has important implications (eg. the sizes make no sense and maybe the "reuse" flags from The approach to sizes also change. See a separate comment about that. |
Beta Was this translation helpful? Give feedback.
-
Idea 2. One more step from the current UI to the Expert PartitionerThis implies merging the "Installation devices" mentioned on idea 1 and the list of filesystems. The same kind of devices can be added to that list - ie. disks, volume groups (new or reused) and RAIDs (new or reused) - and each device still receives an alias. But many other aspects are different from idea 1 Adding a device implies adding also the underlying ones. Eg. if a new LVM is defined with automatically generated PVs as partitions on "sdb", then both the new VG and sdb will be displayed on the list. Even if sdb is used only to host those automatic PVs and nothing else. The disk selected for booting (if any) is also part of the list. Even if it's not used for any other purpose. The devices in the list can be directly formatted or contain a list of partitions/lv. In both cases, that information is displayed next to its corresponding device. Let's imagine the system is configured to boot from sda but the filesystems will be created as new logical volumes on top of a new LVM with auto-generated partitions on sdb. And to make things a bit more interesting, let's say a previously existing partition from sdb will be reused. Conceptually that would look like (of course, the representation may vary a lot from what can be expressed with HTML unordered lists).
The entries in italic represent aspects that are defined indirectly (eg. using the boot settings or creating a new generated volume group on top of the device). In any case, all the information in the list above can be directly obtained from The actions to make space on existing devices (what to resize/delete) is defined by device instead of globally. The option is accessed from each entry at the above list. In the case of directly formatted devices the content is always deleted so there is nothing to influence (although the information is still displayed). Eg.
Note the previous example could end up placing It would make sense to have a way to specify "default" as part of the list of partitions for a disk. Then the UI could generate a config like this: { "storage": {
"disks": [
{ "search": "/dev/sda", "partitions": ["default"] }
]
} }That would look like this
Even without having executed the proposal yet, that information can actually be already expanded to a so-called "resolved" object
Note the root and swap partitions are italic because they are not explicitly specified, they are the consequence of selecting sda as the target for the default filesystems. Probably the concept will not scale very well to represent something like this { "storage": {
"drives": [...],
"mdRaids": [
"generate": {
"mdRaids": "default",
"level": "raid0",
"devices": [
{ "generate": ["sda", "sdb"] }
]
}
]
} }But still worth exploring. Likely the settings for encryption could also be integrated in the same box. So all the settings (boot settings, drives, partitions, lvm...) will be defined in one box. The result could also be merged into a single box or kept as two separate ones for "Actions" and "Final layout". Take into account "Actions" would become less relevant because the so called SpaceActions are now configured for each device together with other aspects. To be discussed: displaying sizes at the configThe list above does not display the sizes of the proposed partitions or logical volumes. That's debatable, but I think showing the size limits may be confusing. Maybe an alternative would be to only display size limits when they are explicit, as opposed to the omitted ones that are actually the default case (or that's what we expect). In any case, there must be ways to check which min and max sizes were used, no matter if explicitly set by the user or inferred by Agama. And in the second case (omitted sizes) the explanation for the used limits (eg. based on RAM) should also be presented. But maybe all that information should only be revealed when needed. For example, when editing a filesystem or when clicking on some "explain me this" button/hover. |
Beta Was this translation helpful? Give feedback.
-
Idea 2bis.This reply presents some possible modifications over idea 2. Basically, it merges in the list of settings some information about how the final result will look like. We need to decide whether that helps to understand the settings or introduces more confusion. From a technical point of view, it means the represented list of settings is not a direct representation of The first example would turn into something like this:
The most obvious difference is the sizes. See also that the actions to make space are more specific, not only explaining what is configured but also exactly how many partitions are effectively affected. In addition, "partitions needed for booting" is actually replaced by a more concrete explanation of what will be done in that regard. Last but not least, the message about auto-generated PVs for vg_system could be more explicit indicating the number of PVs created on that concrete disk. The second example would not change that much, but still would include several more details about final sizes, about deleting and about booting.
The third example would be very similar to one of the alternatives presented at idea 2.
To be discussed: displayed sizesThe sizes displayed in all the previous examples are the final ones after generating the proposal. Everything mentioned at idea 2 about displaying (and explaining) the size limits (explicit or not) when editing the entry (and/or with some other mechanism) still applies. |
Beta Was this translation helpful? Give feedback.
-
|
Based on an offline conversation with @dgdavid, this would be a first (very quick) attempt to have collapsed items at the list of devices. I will put more time into it when I have more time. Full
Collapsed
"Boot disk" could even be an icon. Full
Collapsed
Full
Collapsed
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks a ton @ancorgs! |
Beta Was this translation helpful? Give feedback.
-
|
What about sharing this idea to a more wide audience? At least with the rest of the team. Maybe we gather some interesting feedback. Or at least to have a serious review after the first iteration with a "read only" interface. |
Beta Was this translation helpful? Give feedback.
-
|
Sure. We are working on it and writing it here and not keeping it private was a way of sharing. @ancorgs not only wrote it here for publishing with some context, but also put the link in the IRC channel where usually the rest of the team is. When we have a clear idea of the UI, we can publish it for gathering feedback. Meanwhile we are just trying to shape it. Hope you understand that involving too many people in that phase could be a bit challenging. Nevertheless, we are open to listen/read ideas if someone have one. |
Beta Was this translation helpful? Give feedback.
-
Idea 3. Expert Partitioner with "Helpers"Having something like the Expert Partitioner is perfectly doable thanks to the power of the agama proposal and the storage config. The UI would consist on a single table of devices, always showing the result. This is similar to what the current UI does in the result box.
The UI offers a set of actions for each device:
Moreover, there would be some "advanced forms" (i.e., helpers) to easily perform certain actions. For example:
From the implementation point of view, the UI does not need to understand the storage config in order to draw the table of devices. It simply uses the "devicegraph" (as the result does). All the possible actions are already (or will be) supported by the agama proposal, so the UI only has to generate the proper storage config for the requested action. For example:
{
"drives": [
{
"search": "/dev/vda",
"partitions": [
{
"size": "10 GiB",
"filesystem": {
"type": "xfs",
"path": "/home"
}
}
]
}
]
}
{
"drives": [
{
"search": "/dev/vda",
"partitions": [
{
"search": "/dev/vda1",
"delete": true
}
]
}
]
}
{
"drives": [
{
"search": "/dev/vda",
"alias": "vda"
},
{
"search": "/dev/vdb",
"alias": "vdb"
}
]
"volumeGroups": [
{
"physicalVolumes": [
{ "generate": ["vda", "vdb"] }
]
}
]
}
{
"drives": [
{
"search": "/dev/vda",
"partitions": [
{
"sectorStart": 12442323342,
"size": "10 GiB",
"filesystem": {
"type": "xfs",
"path": "/home"
}
}
]
}
]
}The storage config only needs to add a property in the partition schema (e.g., sectorStart) to indicate the number of the first sector of a free partition slot. Note that this information is already reported by the devices and it is used in the space policy dialog for sorting partitions. Getting the Resulting ConfigThe resulting "solved" config can be automatically generated from the probed and the staging devicegraphs. For example, let say we have resized vda1, deleted vda2 and created a new partition. The resulting config would look like the following: {
"drives": [
{
"search": "/dev/vda",
"partitions": [
{
"search": "/dev/vda1",
"size": "2 GiB"
},
{
"search": "/dev/vda2",
"delete": true
}
{
"sectorStart": 12442323342,
"size": "10 GiB",
"filesystem": {
"type": "xfs",
"path": "/home"
}
}
]
}
]
} |
Beta Was this translation helpful? Give feedback.
-
The overall idea
Let's start with a quick reminder of the current UI. It looks like this...
... and generates an object
ProposalSettingswith a relatively high level of abstraction. That is used as input for an algorithm relatively similar to the YaST Guided Setup.On the other hand, when working on unattended mode, Agama takes an input an object
Storage::Configthat is described at auto_storage.md (see the latest pull request). That format allows to express everything that can be expressed viaProposalSettingsand also many more things like creation of MD RAIDs.We are considering to change the general approach of the UI to read and generate
Storage::Configand completely kill the concept ofProposalSettings. In fact, that was the original concept a couple of years ago, but we deviated from it for several reasons.Let's use this discussion to propose ideas and alternatives following that core principle: working with
Storage::Configobjects and always running the same algorithm of the unattended installation.Changing the approach to sizes
Each entry at the filesystems box in the current UI corresponds to the underlying concept of one volume of
ProposalSettings. And it's possible to specify a size of "auto" for a filesystem (volume). That value can only be used on some volumes that support that. Because that "auto" flag only makes sense on the (pretty artificial) world of the volumes and means a volume can follow a relatively complex logic to calculate its size limits (adapted to RAM, grow if there is no separate home, etc.). For example, at Tumbleweed "/home" has a default max and min, but no "auto" because those size limits (min and max) are always the same.The new interfaces will still have a list of filesystems in one way or another. But the entries will not be translated into volumes for
ProposalSettings. Very likely each entry will represent an elementfilesystemof theStorage::Config, together with the corresponding partition/lv that will be created to host that filesystem.That's also a nice opportunity to modify/kill the concept of "auto" in the UI.
At
Storage::Configsizes for devices can be omitted and Agama will do the appropriate thing. From that point of view and following the previous example, omitting the sizes of "/home" is not different from omitting the size of a volume with automatic sizes. The real decision is "I will enter my own size (or size limits)" vs "I will let the installer decide on the size". How then the installer decides the sizes on that second case is important but secondary.Take into account there are also situations in which specifying sizes simply makes no sense. Eg. when directly formatting/mounting a device instead of creating a new partition/lv.
So setting your own size limits for a given mount point feels more like an optional thing that can be done by the user in some situations. But it makes sense if the default at the UI is omitting the size and letting the installer decide.
Beta Was this translation helpful? Give feedback.
All reactions