Project

General

Profile

Actions

action #65804

open

[opensuse] test fails in prepare_test_data

Added by dimstar_suse over 4 years ago. Updated 9 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
-
Start date:
2020-04-18
Due date:
% Done:

0%

Estimated time:
Difficulty:

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

Actions #1

Updated by favogt over 4 years ago

The test data includes ai_ml now, which is over 100MiB in size...

Actions #2

Updated by okurz over 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.

Actions #3

Updated by ggardet_arm over 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
Actions #4

Updated by ggardet_arm over 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?

Actions #5

Updated by okurz over 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?

Actions #6

Updated by ggardet_arm over 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.

Actions #7

Updated by okurz over 4 years ago

sure, do that.

Actions #8

Updated by ggardet_arm over 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.

Actions #9

Updated by okurz over 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.

Actions #10

Updated by ggardet_arm over 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.

Actions #11

Updated by okurz over 3 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".

Actions #12

Updated by slo-gin over 2 years 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.

Actions #13

Updated by slo-gin 9 months 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.

Actions

Also available in: Atom PDF