Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge master into the architecture_2024 branch #1102

Merged
merged 42 commits into from
Mar 19, 2024

Conversation

imobachgs
Copy link
Contributor

Keep the architecture_2024 in sync with the master branch.

ancorgs and others added 30 commits March 6, 2024 14:43
## Problem

We need authorization token from the web server to be able to proceed with subsequent
commands


## Solution

```agama server login``` asks for JWT and stores it into a well-known file
```agama server logout``` deletes stored JWT
```agama server shows``` stored JWT if any

## Testing

- *Tested manually*
dgdavid and others added 12 commits March 7, 2024 15:16
Inspired in PF/Alert component, but much more simpler.
To make use of core/Reminder and return undefined as soon as possible.
Commit also add few changes to helper method.
…torage page (#1075)

## Problem

Agama shows a message in the storage screen if the product being
installed uses a transactional Btrfs as root file-system (ie. read-only
root subvolume and Btrfs snapshots as a mechanism to perform updates).
But that message was displayed in the middle of the "Settings" section
taking the place usually occupied by the Btrfs snapshots switch. Having
it there didn't make much sense.

![Old
screen](https://github.com/openSUSE/agama/assets/3638289/7e4d472e-3d9e-4fab-b5b3-f3dd6b4369dc)

Moreover, the sentence was a bit complicated and it was not so clear how
the statement was related to other settings in the same page.

## Solution

The message is now displayed at the top of the page and the wording has
been slightly modified to, hopefully, explain why some of the usual
configuration options (like disabling Btrfs snapshots or changing the
file-system type for "/") are not available.


![micro-reminder](https://github.com/openSUSE/agama/assets/1691872/12a55af3-e5ec-4ff2-a3b1-fe6e9e22c5a5)


If the system is not transactional, everything looks as before, as
displayed in the following screenshots.


![macro2](https://github.com/openSUSE/agama/assets/3638289/f89ab1f3-72ea-4ebe-8581-03fb90ad2f0d)

## Testing

- Tested manually
- Updated unit tests

## Note

This is broken into many small commits to ease collaboration during
development. The plan is to squash when merging.
- agama.gemspec was renamed, see
  #1056.
- The file name was not updated in the rubocop config.
## 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 |
|-|-|
|
![by_ram](https://github.com/openSUSE/agama/assets/3638289/a6a2aedd-b630-4346-8d16-6c2cc2fa6d85)
|
![enlarge](https://github.com/openSUSE/agama/assets/3638289/2f0443ae-a732-40af-a858-f8314d48ad19)
|

## 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 |
|-|-|
|
![ram-table](https://github.com/openSUSE/agama/assets/3638289/ec742117-6859-462c-8a9c-460c1509bf43)
|
![ram-form](https://github.com/openSUSE/agama/assets/3638289/3fd74029-196c-4b4f-9da5-74e5efbe52e0)
|

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).
@coveralls
Copy link

Coverage Status

coverage: 73.89% (-0.3%) from 74.145%
when pulling 0bbdef8 on merge-master-architecture_2024
into d6c3fc0 on master.

@imobachgs imobachgs changed the base branch from master to architecture_2024 March 18, 2024 21:16
@mchf
Copy link
Contributor

mchf commented Mar 19, 2024

LGTM (but the React part ... but that is my personal problem with React ;-))

@imobachgs imobachgs merged commit 744b680 into architecture_2024 Mar 19, 2024
3 checks passed
@imobachgs imobachgs deleted the merge-master-architecture_2024 branch March 19, 2024 09:12
imobachgs added a commit that referenced this pull request May 6, 2024
After a few months of work, it is time to merge the `architecture_2024`
branch into `master`. It is still a work-in-progress, but all the
efforts should be go now against that branch.

## Pull requests

* #1061
* #1064
* #1073
* #1074
* #1080
* #1089
* #1091
* #1092
* #1094
* #1095
* #1099
* #1100
* #1102
* #1103
* #1112
* #1114
* #1116
* #1117
* #1119
* #1120
* #1123
* #1126
* #1129
* #1130
* #1131
* #1132
* #1133
* #1134
* #1136
* #1139
* #1140
* #1143
* #1146

## Other commits

* 8efa41f
* 9e2dec0
@imobachgs imobachgs mentioned this pull request May 17, 2024
imobachgs added a commit that referenced this pull request May 17, 2024
Prepare for releasing Agama 8. It includes the following pull requests:

* #884
* #886
* #914
* #918
* #956
* #957
* #958
* #959
* #960
* #961
* #962
* #963
* #964
* #965
* #966
* #969
* #970
* #976
* #977
* #978
* #979
* #980
* #981
* #983
* #984
* #985
* #986
* #988
* #991
* #992
* #995
* #996
* #997
* #999
* #1003
* #1004
* #1006
* #1007
* #1008
* #1009
* #1010
* #1011
* #1012
* #1014
* #1015
* #1016
* #1017
* #1020
* #1022
* #1023
* #1024
* #1025
* #1027
* #1028
* #1029
* #1030
* #1031
* #1032
* #1033
* #1034
* #1035
* #1036
* #1038
* #1039
* #1041
* #1042
* #1043
* #1045
* #1046
* #1047
* #1048
* #1052
* #1054
* #1056
* #1057
* #1060
* #1061
* #1062
* #1063
* #1064
* #1066
* #1067
* #1068
* #1069
* #1071
* #1072
* #1073
* #1074
* #1075
* #1079
* #1080
* #1081
* #1082
* #1085
* #1086
* #1087
* #1088
* #1089
* #1090
* #1091
* #1092
* #1093
* #1094
* #1095
* #1096
* #1097
* #1098
* #1099
* #1100
* #1102
* #1103
* #1104
* #1105
* #1106
* #1109
* #1110
* #1111
* #1112
* #1114
* #1116
* #1117
* #1118
* #1119
* #1120
* #1121
* #1122
* #1123
* #1125
* #1126
* #1127
* #1128
* #1129
* #1130
* #1131
* #1132
* #1133
* #1134
* #1135
* #1136
* #1138
* #1139
* #1140
* #1141
* #1142
* #1143
* #1144
* #1145
* #1146
* #1147
* #1148
* #1149
* #1151
* #1152
* #1153
* #1154
* #1155
* #1156
* #1157
* #1158
* #1160
* #1161
* #1162
* #1163
* #1164
* #1165
* #1166
* #1167
* #1168
* #1169
* #1170
* #1171
* #1172
* #1173
* #1174
* #1175
* #1177
* #1178
* #1180
* #1181
* #1182
* #1183
* #1184
* #1185
* #1187
* #1188
* #1189
* #1190
* #1191
* #1192
* #1193
* #1194
* #1195
* #1196
* #1198
* #1199
* #1200
* #1201
* #1203
* #1204
* #1205
* #1206
* #1207
* #1208
* #1209
* #1210
* #1211
* #1212
* #1213
* #1214
* #1215
* #1216
* #1217
* #1219
* #1220
* #1221
* #1222
* #1223
* #1224
* #1225
* #1226
* #1227
* #1229
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants