Bug 1022010 - node sync: 'NoneType' object is unsubscriptable (though sync continues on child)
node sync: 'NoneType' object is unsubscriptable (though sync continues on child)
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Hammer (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: Unspecified
: --
Assigned To: Justin Sherrill
Katello QA List
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2013-10-22 09:33 EDT by Corey Welton
Modified: 2014-05-23 17:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-05-23 17:46:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Corey Welton 2013-10-22 09:33:20 EDT
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):

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 13:28:47 EDT
Justin, if you can reliably reproduce this, can we investigate a fix for MDP2?
Comment 3 Justin Sherrill 2013-10-23 14:04:10 EDT
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)
            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 17:46:31 EDT
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.

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