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
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
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.
Errata are cloned, and pkgs are added.
Confirmed bug w/ Justin.
Point 2 is correct. The fix is available in
Regarding point 1, I'd say the behavior is correct. For adding packages there's another api call: channel.software.mergePackages.
Please, ignore my previous comment regarding point 1.
It makes sense to associate packages, when merging errata.
Fix also for mergeErrata with given start and end date
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]
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.
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.
Yes, it's reproducable.
Note if a customer requests a hotfix for this bug, available packages are found here:
Created attachment 445978 [details]
This is the traceback I get, while deleting the cloned channel.
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.
Thanks Tomas for clarification.
Changing to VERIFIED:
Merging errata between multiple channels.
Approving bug 642287 - this bug needs to be re-QA'd once bug 642287 is ON_QA.
Retested on sat530 and Sat540. And behaviour is the same.
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.
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.