Project

General

Profile

Actions

Bug #5960

closed

Need to determine Applicability API completion based on status field vs finished_time

Added by Justin Sherrill over 10 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
High
Category:
-
Target version:
Difficulty:
Triaged:
Yes
Fixed in Releases:
Found in Releases:

Description

There are times when there may not be a "finished_time" field set on the return results of an API call to pulp's applicability API.

This results in Katello's CV publish being stuck in the 'pending' state and is not the best way to determine if an API call is finished or not.

The better way is to use the status field of the API call and poll that to see if a task/call is complete.

IRC convo for context:

<jsherrill> mmccune: suspended is commong for remote tasks (like pulp tasks) when the task is sleeping waiting for it to finish in pulp
<jsherrill> finish_time:
<jsherrill> there's no finish_time!
<jsherrill> that's how we figure out if a task if actually finished or not
<mmccune> ahh
<jsherrill> rbarlow: applicability generation question ^
<jsherrill> why is finish_time blank on applicability_generatin ?
<jsherrill> generation*
<jsherrill> is that expected?
<rbarlow> hmmm, that isn't expected to me
<rbarlow> though, i would suggest against using finish_time to know if a task is finished
<rbarlow> i would recommend making a set of "final states" and checking to see if state is in that set
<rbarlow> things like failed, canceled, finished
<rbarlow> that mgiht be all of them
<jsherrill> rbarlow: yeha i'm not sure why we do
<rbarlow> actually i know a weird thing i did that might make finish time not always be present - if you cancel a task, it most often won't get a finish_time, but it will get one if its a sync or a publish
<rbarlow> it's implementation details
<mmccune> in this case, i didnt cancel
<rbarlow> and i was hoping to find time to fix that, but it didn't seem as important as other problems we've got right now ☺
<rbarlow> yeah i was just mentioning it so you knew that finish_time was a "best effort" and not a guarantee
<rbarlow> i would like to fix that
<rbarlow> but in the meantime, i'd suggest that it's probably better to use the task state anyway - that's what it's for
<jsherrill> rbarlow: yeah, mmccune mind filing an issue for that?
<mmccune> on it
<jsherrill> thanks

Actions #1

Updated by Justin Sherrill over 10 years ago

  • Bugzilla link set to https://bugzilla.redhat.com/show_bug.cgi?id=1099668
Actions #2

Updated by Justin Sherrill over 10 years ago

  • Target version set to 45
Actions #3

Updated by Justin Sherrill over 10 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100

Applied in changeset katello|commit:be2bfcf20321759796c42c22df89fd6c9426c4c2.

Actions #4

Updated by Eric Helms over 10 years ago

  • Triaged changed from No to Yes
Actions

Also available in: Atom PDF