Bug 983400 - spacecmd do_ssm_intersect() returns a list instead of dict
spacecmd do_ssm_intersect() returns a list instead of dict
Status: CLOSED CURRENTRELEASE
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
1.10
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stephen Herr
Red Hat Satellite QA List
:
Depends On:
Blocks: space20
  Show dependency treegraph
 
Reported: 2013-07-11 02:59 EDT by mertensb
Modified: 2013-08-02 09:16 EDT (History)
2 users (show)

See Also:
Fixed In Version: spacecmd-1.10.6-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-02 09:16:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to ssm.py (708 bytes, text/plain)
2013-07-11 02:59 EDT, mertensb
no flags Details

  None (edit)
Description mertensb 2013-07-11 02:59:57 EDT
Created attachment 772036 [details]
patch to ssm.py

Description of problem:
In spacecmd the system set manager list of systems is changed from a dict to a list after using ssm_intersect causing future operations on the set to fail. 

Version-Release number of selected component (if applicable):
[mertensb@defrladm001 ~]$ rpm -q spacecmd
spacecmd-1.2.2-1.el5


How reproducible:
every time

Steps to Reproduce:
1. start spacecmd
2. ssm_clear
3. ssm_add group:GROUP1
4. ssm_intersect group:GROUP2
5. try any operation that operates on the ssm e.g. "group_addsystems GROUP3 ssm" or "system_setbasechannel ssm dev-rhel-x86_64-server-6"

Actual results:
spacecmd {SSM:5}> system_setbasechannel ssm dev-rhel-x86_64-server-6
ERROR: 'list' object has no attribute 'keys'


Expected results:
spacecmd operates on systems in ssm

Additional info:
The problem is caused by the ssm_intersect:
spacecmd {SSM:2}> group_addsystems HP-DEV ssm
ERROR: 'list' object has no attribute 'keys'
Traceback (most recent call last):
  File "/usr/bin/spacecmd", line 153, in ?
    shell.cmdloop()
  File "/usr/lib64/python2.4/cmd.py", line 142, in cmdloop
    stop = self.onecmd(line)
  File "/usr/lib64/python2.4/cmd.py", line 219, in onecmd
    return func(arg)
  File "/usr/lib/python2.4/site-packages/spacecmd/group.py", line 52, in do_group_addsystems
    systems = self.ssm.keys()
AttributeError: 'list' object has no attribute 'keys'

Doing the same operation on the same selection of servers but without the intersect works:
spacecmd {SSM:2}> ssm_clear
spacecmd {SSM:0}> ssm_add lemansdbdvlsrv.mle.mazdaeur.com
DEBUG: Added lemansdbdvlsrv.mle.mazdaeur.com
DEBUG: Systems Selected: 1
spacecmd {SSM:1}> ssm_add defrldas001.mle.mazdaeur.com
DEBUG: Added defrldas001.mle.mazdaeur.com
DEBUG: Systems Selected: 2
spacecmd {SSM:2}> group_addsystems HP-DEV ssm
spacecmd {SSM:2}>

I'm no expert but I believe the problem is the following:
In shell.py the ssm is configured as a dict:
 52     def __init__(self, options):
 53         self.session = ''
 54         self.username = ''
 55         self.server = ''
 56         self.ssm = {}

But in ssm.py the do_ssm_intersect returns a list:
98 def do_ssm_intersect(self, args):
 99     (args, options) = parse_arguments(args)
...
113     tmp_ssm = []
114     for system in systems:
115         if system in self.ssm:
116             logging.debug('%s is in both groups: leaving in SSM' % system)
117             tmp_ssm.append(system)
118
119     # set self.ssm to tmp_ssm, which now holds the intersection
120     self.ssm = tmp_ssm

At this point self.ssm is a list not a dict causing the self.ssm.keys() to fail.

The attached patch solves the issue for me.
Comment 1 Stephen Herr 2013-07-11 11:09:30 EDT
Hi Bram, 

That's an extremely detailed bug report, thanks for that and for the patch. Reviewed and committed as e485f0a584886b8941b3ac652920541d2c5996bc (with one small modification, since self.ssm already knows the system_id of the system there's no reason to initiate the xmlrpc call of get_system_id again).
Comment 2 Tomáš Kašpárek 2013-08-02 09:16:29 EDT
Fix for this bug is present in Spacewalk 2.0, closing this bug as CURRENTRELEASE.

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