Cache the software data to avoid blocked UI during package installation #2364
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lslezak
commented
May 20, 2025
imobachgs
approved these changes
May 20, 2025
3 tasks
imobachgs
added a commit
that referenced
this pull request
May 22, 2025
## Problem It is a known problem that the software service can get blocked at several stages and it has an impact in the UI and the CLI. We mitigated that problem in #2364 but there are still some cases that are not handled properly. For instance, during software probing, Agama is not able to return the list of issues. we could argue whether the list of issues is still valid, but that's a different topic. At least, Agama should return something. ## Solution This PR implements a new `IssuesService` which handles and caches the issues for any service. At this point, it is only used by the software service, but the idea is to use it from all the services. Apart from caching the issues, it offers a centralized way of keeping track of the issues, listening for changes in single place (instead of building and processing an stream of events for each of the services). For instance, the iSCSI API was not emitting the `IssuesChanged` events because we forgot to add the call to `issues_stream`. Now, it is done automatically. The service uses [Tokio channels](https://tokio.rs/tokio/tutorial/channels) and message passing to [share the state](https://tokio.rs/tokio/tutorial/shared-state). > [!NOTE] > The problem is not fully solved because the "can_install" function still relies on D-Bus, which still blocks. ## Testing - Tested manually ## Tasks - [x] Implement an IssuesService. - [x] Emit the events from the service itself. - [x] Adopt `IssuesService` in other services. ## Follow ups Most probably, we should implement a mechanism like this for progress tracking too, although given to the amount of progress signals it is rarely a problem.
imobachgs
added a commit
that referenced
this pull request
May 23, 2025
## Problem Follow-up of #2379. It is a known problem that the software service can get blocked at several stages and it has an impact in the UI and the CLI. We handled part of that problem in #2364 and #2379, but there are still some cases that are not handled properly. For instance, during software probing, Agama is not able to return the current progress. ## Solution This PR implements a new `ProgressService` which handles and caches the progress for any service. Apart from caching the progress, it offers a centralized way of keeping track of the progress, listening for changes in single place (instead of building and processing an stream of events for each of the services). The service uses [Tokio channels](https://tokio.rs/tokio/tutorial/channels) and message passing to [share the state](https://tokio.rs/tokio/tutorial/shared-state). As part of this change, I have decided to introduce a new `ProgressChanged` signal, which carries the information we need, instead of relying on the generic `PropertiesChanged`. ## Testing - Tested manually - An ISO is [temporarily available](https://download.opensuse.org/repositories/systemsmanagement:/Agama:/branches:/non-blocking-progress/images/iso/).
Merged
imobachgs
added a commit
that referenced
this pull request
May 26, 2025
Prepare to release Agama 15: * #2258 * #2270 * #2277 * #2279 * #2283 * #2284 * #2285 * #2286 * #2287 * #2288 * #2291 * #2292 * #2293 * #2295 * #2297 * #2299 * #2300 * #2301 * #2302 * #2303 * #2305 * #2306 * #2307 * #2308 * #2309 * #2313 * #2314 * #2315 * #2317 * #2318 * #2319 * #2320 * #2321 * #2322 * #2323 * #2324 * #2325 * #2328 * #2329 * #2330 * #2331 * #2335 * #2336 * #2337 * #2338 * #2339 * #2340 * #2342 * #2345 * #2346 * #2348 * #2349 * #2350 * #2351 * #2352 * #2353 * #2354 * #2355 * #2357 * #2358 * #2359 * #2360 * #2361 * #2362 * #2363 * #2364 * #2365 * #2366 * #2368 * #2369 * #2370 * #2371 * #2372 * #2374 * #2377 * #2378 * #2379 * #2380 * #2381 * #2382 * #2384 * #2385 * #2386 * #2388 * #2389 * #2390 * #2391 * #2392 * #2394 * #2397 * #2398 * #2401 * #2403
imobachgs
added a commit
that referenced
this pull request
Jul 2, 2025
## Problem Some time ago we, we introduced [a cache](#2364) to store the software data and avoid blocking the UI. The problem is that the list of products is cached only when a client asks for it. So in the case of an unattended installation, it might happen that the installation starts before the web UI asks for the list of products for the first time. - Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1241208 ## Solution Read the list of products during the web server initialization. It will be updated only when the locale changes. ## Testing - *Tested manually*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Details
/api/software/configand/api/software/productsresults are returned after the whole installation is finishedSolution
Testing