action #65804
open[opensuse] test fails in prepare_test_data
0%
Description
Observation¶
openQA test in scenario opensuse-Tumbleweed-Rescue-CD-i686-rescue@32bit fails in
prepare_test_data
The auto-review reruns clearly indicate this to be a test regression (last snapshot/current test = fail, current snapshot / last test ° success)
The live image seems to download too much data, running out of disk space
Test suite description¶
Reproducible¶
Fails since (at least) Build 20200416
Expected result¶
Last good: 20200415 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by favogt almost 4 years ago
The test data includes ai_ml now, which is over 100MiB in size...
Updated by okurz almost 4 years ago
- Subject changed from test fails in prepare_test_data to [opensuse] test fails in prepare_test_data
- Assignee set to ggardet_arm
- Priority changed from Normal to High
Then I suggest the person that introduced this also helps to resolve :)
@ggardet_arm could you please find a better storage location for 100MB of data? The data is copied to many SUTs even though not used.
Updated by ggardet_arm almost 4 years ago
This data/ folder is designed to hold images, scripts, etc. so, this should not be a problem to add things to it.
Do we really need to download the whole data/ folder for this test? I know some tests just download what they need, instead of the whole data/ folder.
Trying to drop the prepare_test_data:
openqa-clone-job --within-instance https://openqa.opensuse.org/tests/1242850 _GROUP=0 EXCLUDE_MODULES=prepare_test_data
Created job #1242934: opensuse-Tumbleweed-Rescue-CD-i686-Build20200421-rescue@32bit -> https://openqa.opensuse.org/t1242934
Updated by ggardet_arm almost 4 years ago
Only textinfo requires data, which is limited to a simple script, so we could update textinfo test to use
assert_script_run('curl ' . data_url('textinfo'));
and drop prepare_test_data module. WDYT?
Updated by okurz almost 4 years ago
sounds good if this can be achieved but still, storing big blobs of binary data in os-autoinst-distri-opensuse also does not sound like the best approach. Maybe we find a better place for that as well?
Updated by ggardet_arm almost 4 years ago
okurz wrote:
sounds good if this can be achieved but still, storing big blobs of binary data in os-autoinst-distri-opensuse also does not sound like the best approach. Maybe we find a better place for that as well?
Eh, I have been told to store it there (by you?). ;) What would you propose then?
IMO, it is ok to store it there, but we should not download the whole data/ folder, but instead, each test should download what it needs.
Updated by ggardet_arm almost 4 years ago
- Status changed from New to In Progress
PR available for textinfo: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10097
Then, we just need to add prepare_test_data to the list in EXCLUDE_MODULES.
Updated by okurz almost 4 years ago
Why not exclude prepare_test_data in the schedule files where we also track history of changes with git, have a place for comments, etc.
Updated by ggardet_arm almost 4 years ago
okurz wrote:
Why not exclude prepare_test_data in the schedule files where we also track history of changes with git, have a place for comments, etc.
Because this is the way currently used for other modules as well.
Updated by okurz over 2 years ago
- Priority changed from High to Normal
This ticket was set to "High" priority but was not updated within 120 days which is 4 times the period of the SLO for "High" tickets (30 days) as described on https://progress.opensuse.org/projects/openqatests/wiki/Wiki#SLOs-service-level-objectives . The ticket will be set to the next lower priority of "Normal".
Updated by slo-gin over 1 year ago
This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.
Updated by slo-gin about 1 month ago
This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.