Bug 1022010 - node sync: 'NoneType' object is unsubscriptable (though sync continues on child)
Summary: node sync: 'NoneType' object is unsubscriptable (though sync continues on child)
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Hammer
Version: Nightly
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: Unspecified
Assignee: Justin Sherrill
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-22 13:33 UTC by Corey Welton
Modified: 2019-09-26 13:43 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-23 21:46:31 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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.


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