openQA Project (public)

With the current approach taken in #38804 it was identified that we do not use the Media2.iso anywhere so maybe we can apply the same approach for e.g. the s390x tests which do not actually use the ISO?

@SLindoMansilla if this is something for you we can work on it pulling it into the current sprint or in next sprint.

I would let it on the next sprint, since it was not planned for the current sprint nor is an urgent issue (or is it? then we could [fast] it)

I have found some places in code where the ISO is used:

• https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/kernel/install_ltp.pm
  • sub add_we_repo_if_available

    elsif (get_var('BUILD_WE') && get_var('ISO_2')) {
        $ar_url = 'dvd:///?devices=/dev/sr2';

• https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/installation/addon_products_sle.pm
  • sub run

            send_key_until_needlematch 'addon-dvd-list',         'tab',  5;     # jump into addon list
            send_key_until_needlematch "addon-dvd-sr$sr_number", 'down', 10;    # select addon in list

In the case of any test suite for ADDONS=(RT, SDK, HA, GEO, WE, etc)

WE¶

• sle-12-SP4-Server-DVD-x86_64-Build0292-we+allpatterns@64bit
  • ISO_5: SLE-12-SP4-WE-DVD-x86_64-Build0125-Media1.iso
• sle-12-SP4-Server-DVD-x86_64-Build0292-we@64bit
  • ISO_5: SLE-12-SP4-WE-DVD-x86_64-Build0125-Media1.iso

• No ISO setting found on https://openqa.suse.de/admin/products for SLE12-SP4
• No ISO setting found on https://openqa.suse.de/admin/test_suites for s390x

The setting has to come from https://gitlab.suse.de/SLindoMansilla/scripts/blob/master/rsync.pl

We can continue looking for more unused ISOs.

bulk move to next sprint as could not be discussed in SR

I need to keep investigating on this ticket. But, at the moment I am working on ticket that needs less time to be resolved.

move due to vacation

guess not …

Moving to sprint 27 since we were not able to resolve it during sprint 26

U-Team agreed that this ticket is usually bigger and more complex than estimated. Let's clarify better and re estimate when the "whole" team is available, on sprint 27 we have 3 people available the whole sprint and 2 for half sprint.

Postponing it to sprint 28

Need to take care of ISO_MAXSIZE https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5931#pullrequestreview-164208877

I would like to see this sooner but right now I do not see the capacity for QSF-u anytime soon

removing #38798 as parent and re-adding as related as the task of the parent was to make sure all assets are accounted for which I think we have. This one is an improvement on top.

time to check that one again after FCS of 15SP1

to be discussed

for grooming

We don't really understand the ticket.
Please explain it better if you want to reopen.

Updated the description, especially with suggestions. I hope this makes it more clear.

needs to be discussed offline

It rather belongs to the tools team (If it's still valid)

szarate wrote:

It rather belongs to the tools team (If it's still valid)

@szarate: Well, I don't think so but maybe you can explain better how you think we could help? I tried with the suggestions in the ticket to make it more clear what would need to be done from the side of test settings and regarding os-autoinst-distri-opensuse, I don't see where this would need anything more from tooling side but I am happy to learn about your opinion then.

szarate wrote:

okurz wrote:

szarate wrote:

It rather belongs to the tools team (If it's still valid)

@szarate: Well, I don't think so but maybe you can explain better how you think we could help? I tried with the suggestions in the ticket to make it more clear what would need to be done from the side of test settings and regarding os-autoinst-distri-opensuse, I don't see where this would need anything more from tooling side but I am happy to learn about your opinion then.

One quick idea that came during the meeting, was for instance:

AC3: Jobs without ISO do not have the setting ISO_MAXSIZE

Have the api call to check for test_suites that allows to do such search.

You can try

openqa-cli api --osd --pretty test_suites | jq '.TestSuites[] | select(.settings[].key == "ISO_MAXSIZE") | {name: .name, id: .id}'

to have a list of all test suites that specify ISO_MAXSIZE. Some are obvious examples where an ISO does not make sense, e.g. "online_sles15sp2_scc_base-srv_all_full_spvm" using PowerVM where an AFAIK ISO can not be directly used. Interesting enough when I call https://openqa.suse.de/tests?match=online_sles15sp2_scc_base-srv_all_full_spvm I don't find any job using that test suite so there are even test suites that are not used at all :(

In general my understanding is that "QE Core" is responsible to ensure a good management of test definitions on OSD, e.g. enforce rules for other teams and such. How about alerts in grafana if there are any unused test suites and references to ISOs when they are not necessary? To remind: The benefit in case this ticket can be resolved would be no useless transfers of unused ISO files back and forth between webUI and workers as well as when cloning to local machines and also less occupied space that could be used for other, more valuable assets, e.g. more qcow files for debugging. If you have good ideas what we can do in "upstream openQA" then this is something which I can of course help more with :)

can you agree with #38807#note-44 ?

okurz wrote:

can you agree with #38807#note-44 ?

no, that's "Solving a problem by tinkering with CLI", how about providing the API call that allows to search for test suites by one or more settings?

If you don't agree, please reject the ticket, instead of playing ping pong.

ok, fine. I can move this ticket back as a potential future task to follow up as SUSE QE Tools. Please keep in mind that I had originally created this ticket as PO for QSF as I see the benefit for test maintainers.

As the settings for openqa.suse.de are SUSE internal we can not easily come up with CI checks in os-autoinst-distri-opensuse that prevent others from adding to the problem. We could come up with CI checks in gitlab though, accept the current state and as a first prevent it from getting worse. What I see as unfortunate though is that many people accept e.g. that assets are needlessly transferred back and forth and extending the time it takes to conduct tests both personally as well as on the production instances. And the SUSE QE Tools team is actually the team that suffers the least from such issues, all other users do though so there should be inherent interest.

Another instance, where this feature would have been helpful

https://suse.slack.com/archives/C02CANHLANP/p1698322687823259?thread_ts=1698226295.765879&cid=C02CANHLANP

I'm moving it to normal, Oli can you can help repurposing the ticket and work together to define it better so Tools can pick it up?