Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1336537

Summary: spacewalk-nightly - spacecmd softwarechannel_adderrata
Product: [Community] Spacewalk Reporter: Bishop Clark <bishop>
Component: APIAssignee: Jiří Dostál <jdostal>
Status: CLOSED NOTABUG QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 2.4CC: jdostal
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-06-20 10:27:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1484117    

Description Bishop Clark 2016-05-16 18:57:50 UTC
Description of problem:
spacecmd softwarechannel_adderrata again giving error message:
ERROR: redstone.xmlrpc.XmlRpcFault: Cloned channel expected: 

Version-Release number of selected component (if applicable):
spacewalk-java-2.5.87-1.el6.noarch
spacecmd-2.5.6-1.el6.noarch

How reproducible:
easily

Steps to Reproduce:
1. start with complete, sound centos6-64 repo, with CEFs run complete
2. create channel 'centos6-64-security', no parents
3. spacecmd -y -q -- centos6-64 centos6-64-security CESA-2016:0494

Actual results:

Security Errata
---------------
CESA-2016:0494  Moderate CentOS kernel Security Update              2016-03-23
Total Errata:     1
ERROR: redstone.xmlrpc.XmlRpcFault: Cloned channel expected: centos6-64-securityerrata


Expected results:

Successfully copying one erratum into the security channel.

Additional info:

currently testing on nightly from a week ago.  Can test on stock 2.4 or new nightly channel, if the latter will once again install successfully.

Comment 1 Bishop Clark 2016-05-16 19:00:54 UTC
this smells like bug 806895 and bug 812053 but I didn't get any usable fixes out of either.  Sorry if it's a true dupe.

Comment 2 Bishop Clark 2016-05-25 06:02:09 UTC
Oops.  Typo in my repro steps.  When I say:

3. spacecmd -y -q -- centos6-64 centos6-64-security CESA-2016:0494

I mean 

3. spacecmd -y -q -- softwarechannel_adderrata centos6-64 centos6-64-security CESA-2016:0494

In short, I forgot the spacecmd command.   Doh!

Comment 3 Jiří Dostál 2016-05-27 11:32:11 UTC
Hello,

I was able to successfully reproduce your issue and made some investigation. Those two bugs you enclosed are not related to this issue, as it uses different API. 

"softwarechannel_adderrata" from spacecmd expects cloned channel as destination channel, because in other case it might happen that it will clone all the errata packages including packages for different OS. 

"softwarechannel_adderrata" calls API 'errata.cloneAsOriginal' which does the check described above. To omit this check you should look at 'errata.clone'. 

Hope this helps

Comment 4 Bishop Clark 2016-05-31 13:33:37 UTC
Is there a subcommand in spacecmd to allow regular access to this API call?  If so, my issue could be more a documentation issue than a code issue.  

If not, and if I prepared the centos6-64-security channel via a command like

spacecmd -q -- \
  softwarechannel_clone \
   -s centos6-64 \
   -n centos6-64-security \
   -l centos6-64-security \
   -p something_else \
   -o 

can I then clone my (one, in this example) Erratum from my source channel to its clone?

spacecmd -y -q -- \
 softwarechannel_adderrata \
 centos6-64 \
 centos6-64-security \
 CESA-2016:0494

I can live with that second solution, I think.  If that will work, it could be all I need.

Comment 5 Bishop Clark 2016-06-01 19:10:51 UTC
Yeah, that mostly works for my needs.  I need to vape the freshly copied payload in order to start fresh and keep the associative link to its parent, but that's it.

So, as above, softwarechannel_clone, and then

spacecmd -q -y -- \
  softwarechannel_removepackages \
  centos6-64-securityerrata \
  '*'

And then we can clone errata by part or by script [1] and we should get the ones we want.


Close me up.

Comment 6 Bishop Clark 2016-06-01 19:14:57 UTC
(with many thanks for your time, and apologies for the spam)

Comment 7 Jiří Dostál 2016-06-20 10:27:16 UTC
I'm glad it helped. Closing this one as "not a bug".

Comment 8 Eric Herget 2017-09-28 18:08:24 UTC
This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.