Bug 1022010

Summary: node sync: 'NoneType' object is unsubscriptable (though sync continues on child)
Product: Red Hat Satellite Reporter: Corey Welton <cwelton>
Component: HammerAssignee: Justin Sherrill <jsherril>
Status: CLOSED UPSTREAM QA Contact: Katello QA List <katello-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: NightlyCC: bbuckingham
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-23 21:46:31 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:

Description Corey Welton 2013-10-22 13:33:20 UTC
Description of problem:
When syncing child nodes, an error is thrown and katello cli bombs out. Sync continues, however, on child. Also note that subsequent syncs of the child nodes did not trigger it.


Version-Release number of selected component (if applicable):
Satellite-6.0.2-RHEL-6-20131017.1


How reproducible:
Not yet sure how reproducible this is, other than I saw it on two separate syncs.  

Steps to Reproduce:
1.  populate katello server, possibly by using omaciel's data population script.  You might want to pare this down to only sync RHEL6 x86_64 and the third party repos.
2.  Attempt to sync a child node.
3.  View results

Actual results:
The katello tool begins sync, and the spinner goes for a while, before erroring out
 'NoneType' object is unsubscriptable

Syncs continue on child however.

Traceback in logs (on parent):

2013-10-21 21:10:42,035 [ERROR][MainThread] error() @ base.py:212 - Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/katello/client/cli/base.py", line 224, in main
    ret_code = super(KatelloCLI, self).main(args, command_name, parent_usage)
  File "/usr/lib/python2.6/site-packages/katello/client/core/base.py", line 312, in main
    return subcommand.main(self.args[1:], self.args[0], self._get_usage_line(command_name, parent_usage))
  File "/usr/lib/python2.6/site-packages/katello/client/core/base.py", line 312, in main
    return subcommand.main(self.args[1:], self.args[0], self._get_usage_line(command_name, parent_usage))
  File "/usr/lib/python2.6/site-packages/katello/client/core/base.py", line 390, in main
    return self.run()
  File "/usr/lib/python2.6/site-packages/katello/client/core/node.py", line 104, in run
    run_spinner_in_bg(wait_for_async_task, [task], message=message)
  File "/usr/lib/python2.6/site-packages/katello/client/lib/ui/progress.py", line 112, in run_spinner_in_bg
    result = function(*arguments)
  File "/usr/lib/python2.6/site-packages/katello/client/lib/ui/progress.py", line 123, in wait_for_async_task
    while task.is_running():
  File "/usr/lib/python2.6/site-packages/katello/client/lib/async.py", line 74, in is_running
    return (len(filter(self._subtask_is_running, self._tasks)) > 0)
  File "/usr/lib/python2.6/site-packages/katello/client/lib/async.py", line 122, in _subtask_is_running
    return task['state'] not in ('finished', 'failed', 'error', 'timed out', 'canceled', 'not_synced')
TypeError: 'NoneType' object is unsubscriptable


Expected results:
Client doesn't die.

Additional info:

Comment 2 Mike McCune 2013-10-23 17:28:47 UTC
Justin, if you can reliably reproduce this, can we investigate a fix for MDP2?

Comment 3 Justin Sherrill 2013-10-23 18:04:10 UTC
Speaking with Corey, he is not able to see this reliably.  Looking at the cli code:

class TaskStatusAPI(KatelloAPI):
    def status(self, taskUuid):
        path = "/api/tasks/%s" % str(taskUuid)
        try:
            task = self.server.GET(path)[1]
        except ServerRequestError:
            task = None
        return task

It appears that anytime there is a server error (Or even a networking error) from a request fetching the status of a task, "None" is returned, which is what happened here.

So without capturing the server logs at the time of the error, there is no way to know what exactly went wrong.  Sadly that server has been wiped.  

I'm going to move to mdp3, if the error does not pop up again, we can just close this issue.

Comment 6 Brad Buckingham 2014-05-23 21:46:31 UTC
The implementation for node (now called capsule) is entirely different and it will not be possible to reproduce the issue, as described.  Per discussion with Corey, we are going to close this one and we can open new BZs for any issues found.