Fix removal of scheduling assets #1811
Conversation
See https://progress.opensuse.org/issues/41483#note-17 - the webui schedules assets while GRU tries to calculate if the asset should be removed. And in between 2 queries the situation changes - causing an early removal
|
Hotpatched on osd |
| @@ -239,6 +239,9 @@ END_SQL | |||
| while (my $result = $max_job_by_group_prepared_query->fetchrow_hashref) { | |||
| my $asset_info = $asset_info{$result->{asset_id}} or next; | |||
| $asset_info->{groups}->{$group_id} = $result->{max_job}; | |||
| if ($result->{max_job} > ($asset_info->{max_job} || 0)) { | |||
| die "$asset_info->{name} was scheduled during cleanup, we are in troubled water"; | |||
|
this lead to quite some failing jobs in about no time. There are enough other cases, but it shows that it happens way more often than what is considered safe for failure. So another option is to rerun the job - or run the whole function in a transaction, which might be the easiest solution. |
So the read-only view isn't bothered by those errors.
Codecov Report
@@ Coverage Diff @@
## master #1811 +/- ##
===========================================
- Coverage 90.4% 71.73% -18.67%
===========================================
Files 139 139
Lines 9878 9882 +4
===========================================
- Hits 8930 7089 -1841
- Misses 948 2793 +1845
Continue to review full report at Codecov.
|
So we don't work with inconsistent data when the asset cleanup is done when scheduling a new ISO.
|
The diff of the last commit affects a lot of lines but I just moved the actual database operations together and put them into a |
See https://progress.opensuse.org/issues/41483#note-17 - the webui
schedules assets while GRU tries to calculate if the asset should
be removed. And in between 2 queries the situation changes - causing
an early removal