Bug 772262 - A promotion which fails returns a pulp error on re-attempting
Summary: A promotion which fails returns a pulp error on re-attempting
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: API
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: Unspecified
Assignee: Tomas Strachota
QA Contact: Jitendra Yejare
URL:
Whiteboard:
Depends On:
Blocks: katello-blockers
TreeView+ depends on / blocked
 
Reported: 2012-01-06 16:06 UTC by Corey Welton
Modified: 2019-02-25 21:56 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-08 03:23:19 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Corey Welton 2012-01-06 16:06:13 UTC
Description of problem:
It's already suboptimal that each push has to be uniquely named. It appears now that in some circumstances, at least, a failed push with a subsequent reattempt fails indicating that (apparently, anyway?) the name has already been used.

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


How reproducible:


Steps to Reproduce:
1. Create an env in ACME_Corporation, "dev"
2.  Sync Some RH content and an EPEL content source
3.  Create a changeset called "todev - 05jan2012_01"; add RH and EPEL content to changeset; review and begin push.
4. The push eventually fails, "Promotion of changeset 'todev - 05jan2012_01' failed. Reason: can't convert Hash into String" 
5. Navigate back to the promotions UI. Note that, indeed, in the rt pane, we see 
"Promotion Failed todev - 05jan2012_01."  Click through.
6. Again, review and attempt to promote.

Actual results:
Failure: Promotion of changeset 'todev - 05jan2012_01' failed.
Reason: Validation failed: Pulp id has already been taken

Not sure where the namespace collision is.

Expected results:
If something fails, we should clean up nicely after ourselves.

Additional info:

Comment 1 Mike McCune 2012-01-17 22:44:37 UTC
This is a backend/API bug.  Sending to BK

Comment 2 Tomas Strachota 2012-02-06 20:12:11 UTC
I couldn't reproduce the problem with katello-0.1.211-1. Do we have version of katello this bug was discovered in? Also a stacktrace would be helpful.

This pulp validation error can appear when there is existing repository with the same id we try to create during promotion. I can simulate such situation but I didn't manage to get there by katello operations.

From the description it seems that something went wrong and we did repo create instead of clone. When promoting for second time the repoid was already taken.

Comment 3 Mike McCune 2012-02-07 20:07:03 UTC
seeing if QA can reproduce

Comment 4 Corey Welton 2012-02-08 03:23:19 UTC
I am no longer able to reproduce this - mostly on account of not being able to reliably get a promotion to fail in such a manner.  Will QA close, can reopen later if it reappears.


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