QA » openQA Project

Note that the asset has apparently been cleaned up in @Xiaojing_liu's test job. But it was there last time I looked at her instance. Likely the asset has been removed by the cleanup (the job is today 14 days old so if she didn't change the default storage duration this is expected).

This let's me of course wonder whether the same has happened for the job mentioned in the job description. However, in this case there's really no trace of the asset being uploaded in the worker log.

It seems there are 2 ways assets can be associated with a job:

1. From the job settings in register_assets_from_settings which is using the previously mentioned asset_type_from_setting function.
2. When the worker has uploaded the asset successfully (see OpenQA::WebAPI::Controller::API::V1::Job::create_artefact).

I suppose 1. has no relevance here because none of the PUBLISH variables are handled here and it nevertheless works in other cases.

Looking at the upload/worker code for 2. it seems that the code is completely independent from job settings. The worker just uploads any file which os-autoinst adds to the assets_public or assets_private directories within the pool directory. Considering that there's no trace of the asset being uploaded in the worker log the asset was likely not even created by os-autoinst. That means the web UI and most likely also the worker are not at fault here. So most likely os-autoinst simply did not create the asset at all. And maybe that's even just because the test didn't reach the point where the asset would be generated (it failed already in update).

That leaves the question why the asset was nevertheless found via https://openqa.nue.suse.com/assets/hdd/bsc1167756_2.qcow2 (the link is dead at this point). An explanation for this is that the URL merely returned the asset created by the previous job (which passed).

The theory that os-autoinst didn't create the asset could be easily checked if autoinst-log.txt would be still there but it isn't.

@leli Before you can show me a more recent example I would postpone putting further effort into this ticket (especially considering that @Xiaojing_liu already tested that is generally works).

By the way, I was trying to find a recent example myself on OSD and o3 via select * from job_settings where key like 'FORCE_PUBLISH_%' order by t_created desc but couldn't find a recent one.

@mkittler the feature "FORCE_PUBLISH" is probably only used when someone manually triggers investigation jobs. I suggest you just select any failing test scenario from a production scenario where it makes sense and trigger a clone with the parameter set.

I could never reproduce it because reproducing it is simply not very straight forward with the information from the ticket description. Maybe I'm also correct and os-autoinst didn't create the asset in this case. I'm unassigning because I've never received any feedback (not even from the author of the ticket) and I assume it does not seem to be very important anymore.

based on #65004#note-9 and more recent comments I suggest we do not try anymore to reproduce the problem but rather try to show a sucessful use of "FORCE_PUBLISH" in a useful way to verify everything works as expected. E.g. find/create a test scenario that should generate and publish an HDD image but fails and force that scenario to publish an image nevertheless with FORCE_PUBLISH.

The pr has been merged

verify run on OSD:https://openqa.suse.de/tests/4850769/file/autoinst-log.txt