Bug 882256 - API call scheduleSyncPackagesWithSystem returns 1 but is doing nothing on my target system
Summary: API call scheduleSyncPackagesWithSystem returns 1 but is doing nothing on my ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Spacewalk
Classification: Community
Component: API
Version: 1.7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stephen Herr
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space27
TreeView+ depends on / blocked
 
Reported: 2012-11-30 14:09 UTC by François BORIE
Modified: 2017-09-28 17:57 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-06 18:07:53 UTC
Embargoed:


Attachments (Terms of Use)

Description François BORIE 2012-11-30 14:09:44 UTC
Description of problem:

I really enjoy using the " sync " packages feature between 2 servers in Spacewalk Web User Interface. Thanks for that !

But I don't succeed to get the API call system.scheduleSyncPackagesWithSystem working ...

I made my tests with 2 servers, which differs only for 2 RPM packages. I do 2 API calls, the first one to get the packages ids to sync, and the second to launch the sync as soon as possible. 

The API logs /var/log/rhn/rhn_web_api.log tells me it's OK, but when going to my target system events via WebUI, I can't see anything (the sync event is not planned at all)

Here are the logs I get : 

[2012-11-30 14:41:25,460] INFO  - REQUESTED FROM: 10.****.98 CALL: system.comparePackages(250857xb800f64807be2c745e7777db35d82126, 1000010166, 1000010165) CALLER: (******) TIME: 0.395 seconds

-> Get the RPM packages list to sync between my 2 systems

[2012-11-30 14:41:37,404] INFO  - REQUESTED FROM: 10.****.98 CALL: system.scheduleSyncPackagesWithSystem(250857xb800f64807be2c745e7777db35d82126, 1000010165, 1000010166, [14202, 2780], Fri Nov 30 14:41:25 CET 2012) CALLER: (***) TIME: 11.926 seconds

-> Launch the sync between these two systems

Version-Release number of selected component (if applicable):

Spacewalk 1.7

How reproducible:

Use the API call system.scheduleSyncPackagesWithSystem

Steps to Reproduce:
1. Get 2 systems with some RPMs packages which differ
2. Get the systems ids and the packages ids to sync
3. Use the API call system.scheduleSyncPackagesWithSystem to launch the sync
  
Actual results:

The API call returns 1, but do nothing. No sync events is displayed either on Pending or Completed events tab. 

Expected results:

An event is created and sync is done

Additional info:

For my 2 test systems, launching a WebUI sync works fine

Comment 1 Stephen Herr 2013-01-03 19:51:18 UTC
Hi François,

This appears to be operating normally for me, are you still having this issue?

If you are, how are you checking for the sync event, from the system-details actions page or from the "Schedule" tab? The sync should show up properly on one of the pending / failed / completed pages, however if you are looking at the actions for an individual system you have to make sure you're looking at the correct system. The first system listed for scheduleSyncPackagesWithSystem is the system being operated on, in your example 1000010165. That will be the system that has the task to add / remove packages depending on what the state of the other system is. If you were to look at the actions for the other system (1000010166) there would not be anything listed.

If you are still having problems, do you see any errors in /var/log/tomcat6/catalina.out when you run the scheduleSyncPackagesWithSystem command?

Comment 2 François BORIE 2013-02-06 18:07:36 UTC
Hi Stephen, 

This ticket can be closed. In fact, I was using wrong packages IDs (package_name_id - returned by API call system.comparePackages - which is different from package id returned by package.findbynvrea) for packages sync between source and target systems 

That looks good now, and that's such an enjoyable feature !

Sorry for that, 

Kind regards, 

François

Comment 3 Eric Herget 2017-09-28 17:57:00 UTC
This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.


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