Description of problem: When creating a base rhel channel and adding child channels that are not red-hat related (i.e puppet or epel) the spacecmd -- softwarechannel_clonetree -o -s ${BASECHANNEL} -p "${NEW_PREFIX}_" --gpg-copy is not cloning any child channel that is alphabetically after the name of the non-rhel child channel (whether rhel or not) Version-Release number of selected component (if applicable): spacecmd-1.8.15-1.el6.noarch How reproducible: Every time in RHEL 6.3 x86_64 sat 5.5 (running on VMWare with latest EL packages). Steps to Reproduce: 1.Import a RHEL base channel to satellite . 2.Import a couple of RHEL child channels i.e. rhn-tools and supplimentary. If you try to clone the tree now, the results should be successfull 3.Create a child channel that is attached to the base channel and import the puppet packages from http://yum.puppetlabs.com/el/6/dependencies/x86_64/. Name the channel and the label puppet-el6. (Import the gpg key from puppetlabs too) 4. Use: spacecmd -- softwarechannel_clonetree -o -s ${BASECHANNEL} -p "${NEW_PREFIX}_" --gpg-copy Actual results: The cloned tree stops at puppet and rhn-tools and supplimentary do not get cloned Expected results: That the command clones the entire subtree including rhel and non rhel child channels. Additional info:
I'm not very convinced about a reproducer, when within a Spacewalk BZ we want to import RHEL channels into the satellite. However I'm adding our spacecmd guys to the BZ, what they say.
I'll take a look at this - agree a spacewalk specific repoducer would be helpful, but when I implemented this feature I tested it on both spacewalk and satellite (5.4.1), so I do expect it to work for the reporters use-case
I can't reproduce on Spacewalk, but I also don't have any proper Red Hat channels. I tried to reproduce based on the naming scheme, but no go. Can you reproduce and run spacecmd with '-dd'? That'll give us as much info as possible. Remember to sanitize the output if you care about the username/password. spacecmd {SSM:0}> softwarechannel_list centos-x86_64-6 centos-x86_64-6-epel centos-x86_64-6-jpackage centos-x86_64-6-spacewalk-client centos-x86_64-6-spacewalk-server puppet-el6 rhel-x86_64-server-6 rhel-x86_64-server-6-optional rhel-x86_64-server-6-supplementary rhn-tools-server-x86_64-6 spacecmd {SSM:0}> softwarechannel_clonetree -o -s rhel-x86_64-server-6 -p test_ --gpg-copy INFO: Cloning rhel-x86_64-server-6 as test_rhel-x86_64-server-6 INFO: Cloning puppet-el6 as test_puppet-el6 INFO: Cloning rhel-x86_64-server-6-optional as test_rhel-x86_64-server-6-optional INFO: Cloning rhel-x86_64-server-6-supplementary as test_rhel-x86_64-server-6-supplementary INFO: Cloning rhn-tools-server-x86_64-6 as test_rhn-tools-server-x86_64-6
Created attachment 639237 [details] spacecmd -dd -- softwarechannel_clonetree output Please see the output of the attachment when running the following (as requested) spacecmd -dd -- softwarechannel_clonetree -o -s rhel-x86_64-server-5 -p "zzz_5_5.0_" --gpg-copy &> file.txt
">ERROR: Name zzz_5_5.0_EPEL 5 x86_64 already in use by channel zzz_5_5.0_epel-5-x86_64" So do you have a naming conflict with an existing channel? Can you please provide the following: spacecmd --debug -- softwarechannel_list -v -t Please provide this output before and after the attempted softwarechannel_clonetree (assuming you're cleaning up manually between attempts), along with the exact command used when doing softwarechannel_clonetree. Perhaps this time just run the clonetree with -d/--debug (not -dd) which will reduce the amount of output and should still be sufficient to see what's happening.
These are the commands I used: [root@hlxd0m001 redhat_scripts]# spacecmd --debug -- softwarechannel_list -v -t &> channels_list.txt [root@hlxd0m001 redhat_scripts] spacecmd -- clear_caches INFO: Connected to http://localhost/rpc/api as satadmin [root@hlxd0m001 redhat_scripts]# spacecmd -dd -- softwarechannel_clonetree -o -s rhel-x86_64-server-5 -p "zzz_5_5.0_" --gpg-copy &> file_5.5.txt [root@hlxd0m001 redhat_scripts]# spacecmd -- clear_caches INFO: Connected to http://localhost/rpc/api as satadmin [root@hlxd0m001 redhat_scripts]# spacecmd --debug -- softwarechannel_list -v -t &> channels_list_after_clone.txt
Created attachment 639395 [details] spacecmd -dd -- softwarechannel_clonetree -o -s rhel-x86_64-server-5 -p "zzz_5_5.0_" --gpg-copy &> file_5.5.txt replaced specific names with zzz
Created attachment 639396 [details] channel list before replaced names with zzz
Created attachment 639397 [details] channel list after clone
So as seen in attachment 639396 [details], spacecmd -- softwarechannel_list -v -t is returning duplicate child channels, which is what is causing the softwarechannel_clonetree to fail. Some debug performed with reporter via IRC which confirmed the following: - spacecmd features which use misc.py::list_base_channels() and list_child_channels() are returning duplicates on the reporters (satellite 5.5) system. - This appears to be a regression in the satellite API, specifically the channel.listSoftwareChannels() call. Ref https://bugzilla.redhat.com/show_bug.cgi?id=500690, we should perhaps replace all of the listSoftwareChannels API calls with listAllChannels, but as noted in 500690 there are some differences in returned fields and scope of returned channels, so this will need some further investigation and testing as we are using it in a few places - perhaps I'll try to look into this if I can find some time. Looking at git logs, I see e8490f8317402a5f142ed9df406336e2afc842bd reworked listSoftwareChannels so if this has been pulled into satellite recently perhaps it could be related? Anwway, since this is not a spacecmd bug, have advised reporter (who is a GPS consultant) to if possible test with a minimal reproducer to figure out which spacewalk-java version introduces the dupes in listSoftwareChannel satellite API output, then raise a case with GSS to get it resolved. So closing this bz NOTABUG since it is not a spacecmd/spacewalk issue (unless anyone can reproduce on spacewalk, which ref comment #3 and my own testing, it seems we cannot)
This BZ closed some time during 2.5, 2.6 or 2.7. Adding to 2.7 tracking bug.