Bug 1320469

So, to the bug report.
I just tested channel.software.mergePackages API call triggers repository metadata regeneration by queuing the request(s) into the rhnRepoRegenQueue table.
Also according to the code, everything looks ok: http://git.rhndev.redhat.com/git/?p=satellite.git;a=blob;f=java/code/src/com/redhat/rhn/frontend/xmlrpc/channel/software/ChannelSoftwareHandler.java;h=4dda940177403ecd64fc28406db8150a1621d561;hb=refs/heads/SATELLITE-5.7#l2267

So, try to make sure taskomatic service is running. You can check in the taskomatic logs the repodata generation has started and finished. Depending on the size of the channel, it can take several minutes to re-generate them.

(In reply to Tomas Lestach from comment #2)
> So, to the bug report.
> I just tested channel.software.mergePackages API call triggers repository
> metadata regeneration by queuing the request(s) into the rhnRepoRegenQueue
> table.
> Also according to the code, everything looks ok:
> http://git.rhndev.redhat.com/git/?p=satellite.git;a=blob;f=java/code/src/com/
> redhat/rhn/frontend/xmlrpc/channel/software/ChannelSoftwareHandler.java;
> h=4dda940177403ecd64fc28406db8150a1621d561;hb=refs/heads/SATELLITE-5.7#l2267
> 
> So, try to make sure taskomatic service is running. You can check in the
> taskomatic logs the repodata generation has started and finished. Depending
> on the size of the channel, it can take several minutes to re-generate them.

Thanks for the update.

Cu has ensured that the taskomatic service is running. And the repodata is still not created.

I can see that the packages are copied to the new channel.

Can you please review the attached script which the Cu is using, is it the issue with the script.

Regards,
Ameya Nerurkar

It tried to reproduce the issue again with following script:
==========================================================================
#!/usr/bin/python

import xmlrpclib

URL = "http://<satellite57_fqdn>/rpc/api"
user = "***"
pswd = "***"
client = xmlrpclib.Server(URL, verbose=0)
session = client.auth.login(user, pswd)
print client.channel.software.mergePackages(session,'rhn-tools-rhel-x86_64-server-7','tml-channel')
client.auth.logout(session)
==========================================================================

I see the appropriate rhnRepoRegenQueue entry immediately after the call and then the repodata generation logs in /var/log/rhn/rhn_taskomatic_daemon.log. Also the repodata in /var/cache/rhn/repodata/tml-channel/ have been refreshed.

I do not see any issues with spacewalk-java-2.3.8-123.el6sat.noarch.

Closing with INSUFFICIENT_INFO.

spacewalk bb3d906ff887c4f3f7340d18fe457a27bdcd46de

(In reply to Tomas Lestach from comment #11)
> It tried to reproduce the issue again with following script:
> ==========================================================================
> #!/usr/bin/python
> 
> import xmlrpclib
> 
> URL = "http://<satellite57_fqdn>/rpc/api"
> user = "***"
> pswd = "***"
> client = xmlrpclib.Server(URL, verbose=0)
> session = client.auth.login(user, pswd)
> print
> client.channel.software.mergePackages(session,'rhn-tools-rhel-x86_64-server-
> 7','tml-channel')
> client.auth.logout(session)
> ==========================================================================
> 
> I see the appropriate rhnRepoRegenQueue entry immediately after the call and
> then the repodata generation logs in /var/log/rhn/rhn_taskomatic_daemon.log.
> Also the repodata in /var/cache/rhn/repodata/tml-channel/ have been
> refreshed.
> 
> I do not see any issues with spacewalk-java-2.3.8-123.el6sat.noarch.
> 
> Closing with INSUFFICIENT_INFO.

The thing that everyone who has looked at this bug misses is that the first request works just fine, and they stop there.  The script that will reproduce the bug does several in a row.  If the call to copy packages and thus to recreate repodata in a subsequent channel comes while the first is still creating the repodata (or perhaps when it is in a certain transient state), the queued request to create repodata in the subsequent channel will be purged along with the completed task for the first channel.  Thus the repodata in the subsequent channel will not be created.  Typically we copy channels for RHEL5, RHEL6 and RHEL7 with some of their child channels, and typically there is one or two of the dozen that don't get the repodata recreated.

VERIFIED on spacewalk-java-2.5.14-104

I could not reproduce it that, but I have tested it with new version and I can not see this problem there.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:3445