action #8082

calculate overall test result in os-autoinst or worker?

Added by lnussel over 4 years ago. Updated 5 months ago.

Status:ResolvedStart date:01/07/2015
Priority:LowDue date:
Assignee:-% Done:

0%

Category:Feature requests
Target version:Done
Difficulty:
Duration:

Description

os-autoinst doesn't know the overall status of a run anymore, it only uploads individual module results the openqa and that one calculates the result when the job is set to done.

When uploading hard disk images however one needs to know the overall status as images shouldn't be uploaded if the test completed but failed

History

#1 Updated by coolo over 4 years ago

I don't want to duplicate the logic - but how about querying openQA for the result before uploading?

#2 Updated by okurz about 4 years ago

  • Category set to 140

#3 Updated by coolo about 4 years ago

I added the job_result to the update_status call, so the worker knows the overall state:
https://github.com/os-autoinst/openQA/pull/499

#4 Updated by okurz over 3 years ago

  • Status changed from New to Resolved

IMHO this is solved. The whole communication protocol was reworked and the status reporting is fine. Also, images to be published are only uploaded for passed jobs.

#5 Updated by coolo over 3 years ago

says who? openQA worker will happily upload images for failed jobs because it doesn't know if the job failed

#6 Updated by okurz over 3 years ago

  • Status changed from Resolved to In Progress

Why don't we have images as assets for failed jobs in the webUI then? Because they are discarded after uploading? If this is the case then it would be a good starting point to preserve qcow images of failed jobs for investigation purposes on demand.

#7 Updated by oholecek over 3 years ago

os-autoinst will not mark the image for upload in case of fatal failure. But will mark it ready to upload in case of failed important test. As of os-autoinst#PR597

#8 Updated by coolo over 3 years ago

we don't want to upload them as the STARTS_AFTER tests should only run on working images. And we don't upload failed images for investigation as we rollback failing job modules - make any hints disappear.

#9 Updated by okurz over 3 years ago

coolo wrote:

we don't want to upload them as the STARTS_AFTER tests should only run on working images. And we don't upload failed images for investigation as we rollback failing job modules - make any hints disappear.

I don't see a general problem with that. My idea was to provide some kind of variable, like we have with KEEPHDDS, which can be used to make all modules fatal, not trigger START_AFTER tests and publish the image maybe even to a special "investigation" space pool with it's own quota where we can store these.

#10 Updated by coolo over 3 years ago

#11 Updated by coolo over 2 years ago

  • Priority changed from Normal to Low
  • Target version set to Ready

this became less relevant as we stopped overwriting disk images on upload, but we still want to avoid uploading failed images. It just doesn't sound too important at this point

#12 Updated by szarate over 2 years ago

  • Status changed from In Progress to Feedback

Nobody is working on this

#13 Updated by coolo over 2 years ago

  • Status changed from Feedback to New

#14 Updated by okurz 8 months ago

  • Category changed from 140 to Feature requests

#15 Updated by okurz 6 months ago

  • Status changed from New to Resolved

so I guess we can state it was done with https://github.com/os-autoinst/os-autoinst/pull/597 . Also there is another, dedicated ticket for the feature request to upload images on demand even from failed jobs (but also not trigger downstream jobs on them)

#16 Updated by coolo 5 months ago

  • Target version changed from Ready to Done

Also available in: Atom PDF