Bug 832354 - spacecmd cache is keeping wrong information
Summary: spacecmd cache is keeping wrong information
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Clients
Version: 1.7
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Aron Parsons
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space19
TreeView+ depends on / blocked
 
Reported: 2012-06-15 08:46 UTC by Jean Roch
Modified: 2013-03-06 15:56 UTC (History)
2 users (show)

Fixed In Version: spacecmd-1.9.3-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-03 23:04:03 UTC
Embargoed:


Attachments (Terms of Use)

Description Jean Roch 2012-06-15 08:46:42 UTC
Description of problem:
The cache of SPACECMD is not uptodate in some case.
This can mislead the real situation

Version-Release number of selected component (if applicable):
spacecmd-1.7.5-1.el5

How reproducible:
For exemple when delete a machine,
Normaly after it has been delete it should not stay in the cache.

spacecmd {SSM:0}> system_delete vmclientsat01       
Profile        System ID     
-------------  ---------
vmclientsat01  1000010803

Delete these systems [y/N]: y
INFO: Deleted 1 system(s)
spacecmd {SSM:0}> system_delete vmclientsat01
Profile        System ID
-------------  ---------
vmclientsat01  1000010803

Delete these systems [y/N]: y
ERROR: redstone.xmlrpc.XmlRpcFault: The following systems were NOT deleted: 
1000010803
spacecmd {SSM:0}> clear_caches
spacecmd {SSM:0}> system_delete vmclientsat01
WARNING: No systems to delete
spacecmd {SSM:0}>

Comment 1 Jean Roch 2012-12-03 17:56:15 UTC
Hello

I updated spacecmd to version spacecmd-1.8.15-1.el5 but the issue is still present.
The cache is not updated after a modification on Satellite (even when made from spacecmd itself) which lead it with wrong informations.

what I have done:
- first clear the cache and rebuild it with a "system_list" command.
- then delete one registered node
- when listing the systems, the node is still present
- "system_details" is giving the error message "No such system - sid = 1000011399"

When a clear_caches is done after each actions inside a scripts, the performances are going down (specialy when processing many systems one after the other).
But this still is better than having a bugy cache.

spacecmd should keep the cache up to date after any modification...


spacecmd {SSM:0}> system_delete vmclientsat01
Profile        System ID
-------------  ---------
vmclientsat01  1000011399

Delete these systems [y/N]: y
INFO: Deleted 1 system(s)
spacecmd {SSM:0}> system_delete vmclientsat01
Profile        System ID
-------------  ---------
vmclientsat01  1000011399

Delete these systems [y/N]: y
ERROR: redstone.xmlrpc.XmlRpcFault: The following systems were NOT deleted: 
1000011399
spacecmd {SSM:0}> system_details vmclientsat01
ERROR: redstone.xmlrpc.XmlRpcFault: No such system - sid = 1000011399

spacecmd {SSM:0}> clear_caches
spacecmd {SSM:0}> system_details vmclientsat01
spacecmd {SSM:0}> system_delete vmclientsat01
WARNING: No systems to delete

Comment 2 Steven Hardy 2013-02-21 11:43:43 UTC
Reassigning to Aron Parsons, spacecmd maintainer

Comment 3 Aron Parsons 2013-03-03 23:04:03 UTC
commit bd42259eb9d71ace802481d836e6595aa876c065

We immediately regenerate the system cache after deleting a system.  However, Spacewalk does not immediately delete the system, so we introduce an artificial delay of 1 second before listing the systems again from the server.  Limited testing shows that this amount of delay is adequate.

I'm going to close the bug.  If your testing shows that this delay does not resolve the issue, we can find another way to handle it.

Comment 4 Jan Pazdziora 2013-03-04 08:08:18 UTC
Aron, we prefer to set the state to MODIFIED when changes were done for the bugzilla, fill the Fixed In Version (I did that now) and leave it for the release nanny to close the bugzilla when the new Spacewalk release is released.


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