Bug 1829390 - Failed hooks dont fail the migration
Summary: Failed hooks dont fail the migration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Migration Tooling
Version: 4.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.4.0
Assignee: Jason Montleon
QA Contact: Xin jiang
URL: https://github.com/konveyor/mig-contr...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-29 13:46 UTC by Sergio
Modified: 2020-05-28 11:10 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-28 11:09:56 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2020:2326 0 None None None 2020-05-28 11:10:21 UTC

Description Sergio 2020-04-29 13:46:18 UTC
Description of problem:
When a hook is added to a migration plan, if this hook fails, the migration is stuck. Even after the hook job reaching the max backoff limit, the migration is not failed and is pending forever.

Version-Release number of selected component (if applicable):
KONVERYOR 1.2

How reproducible:
Always

Steps to Reproduce:
1. Create a migration plan with a prebackup hook that will fail always.
2. Run the migration plan.

Actual results:
The migration is stuck in PreBackupHooks stage. Even if the hook's job reaches the backoff limit

status:
  conditions:
  - lastProbeTime: "2020-04-29T11:45:35Z"
    lastTransitionTime: "2020-04-29T11:45:35Z"
    message: Job has reached the specified backoff limit
    reason: BackoffLimitExceeded
    status: "True"
    type: Failed

Expected results:
The migration should fail once the job reaches the backoff limit and is marked as failed.

Additional info:

Comment 1 Jason Montleon 2020-04-30 14:09:47 UTC
This is a different failure case than I was seeing when I tested. The PR linked will also check for status.conditions[0].reason in addition to status.failed count now.

There was also an overall issue with not calling t.fail when we hit an error. We were logging it but not failing the task. That's fixed here as well.

Comment 5 Sergio 2020-05-08 10:17:55 UTC
Verified in CAM 1.2 stage

After the hook failure, we get this status in the migmigration resource

status:
  conditions:
  - category: Advisory
    durable: true
    lastTransitionTime: "2020-05-08T10:14:49Z"
    message: 'The migration has failed.  See: Errors.'
    reason: PostRestoreHooksFailed
    status: "True"
    type: Failed
  errors:
  - Hook job hookfail-postrestore-lt6fg failed.
  itenerary: Failed
  observedDigest: 7302c6c7dc0e37e5bad574bcb88caba97dcfef0205f47e503cbf6626b71d1250
  phase: Completed

Comment 7 errata-xmlrpc 2020-05-28 11:09:56 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:2326


Note You need to log in before you can comment on or make changes to this bug.