Bug 832354
| Summary: | spacecmd cache is keeping wrong information | ||
|---|---|---|---|
| Product: | [Community] Spacewalk | Reporter: | Jean Roch <jeanroch.rossi> |
| Component: | Clients | Assignee: | Aron Parsons <aronparsons> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Red Hat Satellite QA List <satqe-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 1.7 | CC: | jpazdziora, mmello |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | spacecmd-1.9.3-1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-03-03 23:04:03 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: | 917805 | ||
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
Reassigning to Aron Parsons, spacecmd maintainer 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. 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. |
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}>