action #18076

[tools][openqa-monitoring] no products found, retrying version wildcard

Added by nicksinger almost 3 years ago. Updated 10 months ago.

Status:ResolvedStart date:28/03/2017
Priority:NormalDue date:
Assignee:mkittler% Done:

0%

Category:Concrete Bugs
Target version:Current Sprint
Difficulty:
Duration:

Description

observation

[Tue Mar 28 07:09:40 2017] [31798:warn] no products found, retrying version wildcard
[Tue Mar 28 06:21:26 2017] [25543:warn] no products found, retrying version wildcard
[Tue Mar 28 05:50:48 2017] [14721:warn] no products found, retrying version wildcard
[Tue Mar 28 05:50:49 2017] [14721:warn] no products found, retrying version wildcard
[and many more…]

suggestion

Not sure about the true meaning of this warning but it's lack of information makes this warning almost useless anyway.
Since this is now a known issue, I'll provide a PR for the logwarn-script of okurz to ignore this warning.


Related issues

Copied to openQA Project - action #19730: [tools][openqa-monitoring] "can't remove <needle_path>" Resolved 28/03/2017

History

#1 Updated by okurz almost 3 years ago

https://github.com/okurz/openqa_monitoring/pull/8 merged accepting known failure in monitoring

#2 Updated by okurz over 2 years ago

  • Copied to action #19730: [tools][openqa-monitoring] "can't remove <needle_path>" added

#3 Updated by coolo over 2 years ago

  • Target version set to Ready

this should be debug indeed - useless as warning

#4 Updated by mkittler 12 months ago

Not sure about the true meaning of this warning

It means that an ISO has been posted via the REST API and for the given combination of version, distri, flavor and arch no products could be found. Hence the API tried to find products regardless of the specified version (taking only distri, flavor and arch into account). If that would also not yield any products a real failure would be logged.

@coolo Is this weird behavior of ignoring search parameters on mismatch really needed? I mean, why would one create such a strange API and not simply let the client retry the search?

I'd say this weird behavior should go away and errors of that API should be propagated to the other end and not logged on the server. That should be easy to implement. But how does the client look like? Would it display/log the error then?

#5 Updated by coolo 12 months ago

that's not an API error - it's the true nature of the wildcard. If there wasn't this strange warning, no one would have complained

#6 Updated by mkittler 10 months ago

  • Assignee set to mkittler
  • Target version changed from Ready to Current Sprint

Ok, so let's just remove the warning from the openQA log where it is pretty useless without context and instead add it to the result of the scheduled product instead.

#8 Updated by mkittler 10 months ago

  • Status changed from New to In Progress

#9 Updated by mkittler 10 months ago

  • Status changed from In Progress to Resolved

PR which moves the warning (and similar warnings) to the scheduled products log has been merged.

Also available in: Atom PDF