Bug 591291 - Satellite 5.3: mergeErrata API call does not copy/add packages, it will also associate (instead of clone) non-custom errata to a custom channel (should not be allowed)
Summary: Satellite 5.3: mergeErrata API call does not copy/add packages, it will also ...
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: API
Version: 530
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tomas Lestach
QA Contact: Šimon Lukašík
Depends On:
Blocks: sat531-triage
TreeView+ depends on / blocked
Reported: 2010-05-11 19:47 UTC by Xixi
Modified: 2018-11-14 19:35 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-11-18 08:28:50 UTC
Target Upstream Version:

Attachments (Terms of Use)
catalina.out (11.15 KB, text/plain)
2010-09-08 13:01 UTC, Šimon Lukašík
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0897 0 normal SHIPPED_LIVE Red Hat Network Satellite bug fix update 2010-11-18 08:27:31 UTC

Description Xixi 2010-05-11 19:47:49 UTC
Description of problem:
Running mergeErrata API will associate errata but with 2 issues:
1. no packages are copied/added
2. it does not clone the errata, just associate the original errata, this means it will add non-custom errata to a custom channel, which we've never allowed anywhere

Version-Release number of selected component (if applicable):
Red Hat Network (RHN) Satellite 5.3.0

How reproducible:

Steps to Reproduce:
1. create a clone of the Red Hat Enterprise Linux Desktop (v. 5 for 32-bit x86) channel (chosen arbitrarily) - original state (no errata)
2. run mergeErrata for the cloned channel from original channel

Actual results:
The original errata from original channel are added to the cloned channel, instead of clones of the errata.
No packages for the errata were added to the cloned channel.

Expected results:
Errata are cloned, and pkgs are added.

Additional info:
Confirmed bug w/ Justin.

Comment 2 Tomas Lestach 2010-06-08 12:07:54 UTC
Point 2 is correct. The fix is available in
spacewalk.git: 5c14ba73da7e5f19bdc73092bbfa51f632cb536a

Regarding point 1, I'd say the behavior is correct. For adding packages there's another api call: channel.software.mergePackages.

Comment 3 Tomas Lestach 2010-06-08 15:11:32 UTC
Please, ignore my previous comment regarding point 1.

It makes sense to associate packages, when merging errata.
spacewalk.git: ee10f6731672b225976fdb70a5123f40f6d8cf89

Comment 5 Tomas Lestach 2010-06-30 08:18:44 UTC
Fix also for mergeErrata with given start and end date
spacewalk.git: bc0f1dfe1ca5c7c9910e8c44a2711570f90bb6ae

Comment 6 Stephan Dühr 2010-07-09 15:27:24 UTC
Just wanted to mention that mergeErrata (without given start and end date) in Satellite 5.3 with all updates installed is still broken. The following is logged in /var/log/tomcat5/catalina.out:

2010-07-09 16:40:44,308 [TP-Processor2] WARN  org.hibernate.util.JDBCExceptionReporter - SQL Error: 1, SQLState: 23000
2010-07-09 16:40:44,308 [TP-Processor2] ERROR org.hibernate.util.JDBCExceptionReporter - ORA-00001: unique constraint (RHNSAT.RHN_CE_CE_UQ) violated

2010-07-09 16:40:44,308 [TP-Processor2] ERROR org.hibernate.event.def.AbstractFlushingEventListener - Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: could not insert collection rows: [com.redhat.rhn.domain.channel.Channel.erratas#596]
        at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)

via XMLRPC you just get a "500 Internal Server Error"

When cloning a channel using API call channel.software.clone with original_state=False, the Errata are linked/associated (same errata id), so mergeErrata should do the same. As a workaround, it works to determine the latest update_date of source and target channel and then use mergeErrata with start and end date (each +1), which works fine.

Anyway, mergeErrata should work as fine as mergePackages.

And yes, the other problem is that when cloning via Webinterface, all Errata are cloned (CLA-nnnn:nnnn), see also #568962. When using mergeErrata on such a channel, you get all the original errata, too, so that it would be necesary to use the errata.clone API call on each missing erratum.

Comment 7 Tomas Lestach 2010-07-12 07:58:58 UTC
Hey Stephan,
you're right. The bug is fixed in the upstream and wasn't released as an erratum for sat530 yet (MODIFIED state).
However the traceback you're getting looks like another problem than this BZ.  If you're able to reproduce it, please file another BZ.

Comment 8 Stephan Dühr 2010-07-12 19:35:42 UTC
Yes, it's reproducable.

Comment 10 Justin Sherrill 2010-07-22 19:48:58 UTC
Note if a customer requests a hotfix for this bug, available packages are found here:



Comment 20 Šimon Lukašík 2010-09-08 13:01:07 UTC
Created attachment 445978 [details]

This is the traceback I get, while deleting the cloned channel.

Comment 22 Tomas Lestach 2010-09-09 11:39:26 UTC
The behavior is expected. Because we really clone the errata now, the merge process takes much longer than just the original assigning of errata to another channel.
For channels with bigger amount of errata the process takes longer than the tomcat timeout, so we were forced just to trigger the merge process within the api call and to continue with the process after the api call is finished.
This is the reason, why the cloned errata are not visible right after the api call is finished. The errata get visible after the whole merge process is finished.

Comment 23 Šimon Lukašík 2010-09-09 12:06:01 UTC
Thanks Tomas for clarification.

Changing to VERIFIED:

Testing procedure:
Merging errata between multiple channels. 

Verified against:

Comment 29 Clifford Perry 2010-10-12 14:31:51 UTC
Approving bug 642287 - this bug needs to be re-QA'd once bug 642287 is ON_QA.

Comment 31 Šimon Lukašík 2010-11-08 07:38:40 UTC
Retested on sat530 and Sat540. And behaviour is the same.

Comment 33 Stephan Dühr 2010-11-17 17:11:26 UTC
I just want to add a comment regarding #1 2.: client.channel.software.clone() does link orginal errata, that's where you already allow ist. mergeErrata should behave consistently. If mergeErrata would change in this way, some API scripts used by customer would probably break. I would not consider channels cloned from RH Channels as "custom". They are often used for staging purposes without any custom content.

Comment 34 errata-xmlrpc 2010-11-18 08:28:50 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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