Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1080647

Summary: Traceback on applicability generation for a repository
Product: [Retired] Pulp Reporter: Justin Sherrill <jsherril>
Component: API/integrationAssignee: Sayli Karmarkar <skarmark>
Status: CLOSED CURRENTRELEASE QA Contact: Irina Gulina <igulina>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 2.3CC: cperry, igulina, rbarlow, skarmark
Target Milestone: ---Keywords: Triaged
Target Release: 2.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1080648 (view as bug list) Environment:
Last Closed: 2014-08-09 06:54:48 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: 1080648    
Attachments:
Description Flags
verifiyng screenlog over RHEL6.5 none

Description Justin Sherrill 2014-03-25 21:04:42 UTC
Description of problem:

Currently under certain situations generating applicability will fail.  Some debugging by a bowl of eggs:

  bowlofeggs | jsherrill: i think this might happen if you had applicbility data, a consumer's profile       
             | changes, and then you asked us to regenerate for a repo                                       
  bowlofeggs | yeah, i'm surprised too                                                                       
  bowlofeggs | slight adjustment to what i said, "a consumer's profile changes, and no other consumer shared it's old profile"                                       

Version-Release number of selected component (if applicable):
pulp-server-2.3.1-1.el6.noarch

How reproducible:
Always maybe?

Steps to Reproduce:
1. Register a consumer and bind it to repo A
2. Request applicability regeneration for RepoA
3. Update the consumer's package profile  (make a change)
4. Request applicability regeneration for Repo A again

Actual results:
ERROR (see traceback below)

Expected results:
Regeneration occurs

Additional info:


    2014-03-25 12:58:37,849 [ERROR][3ffb90ed-7893-4892-9726-34ba2f6f6af2] run() @ consumer.py:72 - failed:
    None
    Traceback (most recent call last):
      File "/usr/lib/python2.6/site-packages/gofer/messaging/consumer.py", line 64, in run
        msg = self.__fetch(receiver)
      File "/usr/lib/python2.6/site-packages/gofer/messaging/consumer.py", line 100, in __fetch
        return receiver.fetch(timeout=self.WAIT)
      File "<string>", line 6, in fetch
      File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 1010, in fetch
        self._ecwait(lambda: self.linked)
      File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 50, in _ecwait
        result = self._ewait(lambda: self.closed or predicate(), timeout)
      File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 973, in _ewait
        result = self.session._ewait(lambda: self.error or predicate(), timeout)
      File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 566, in _ewait
        result = self.connection._ewait(lambda: self.error or predicate(), timeout)
      File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 209, in _ewait
        self.check_error()
      File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 202, in check_error
        raise self.error
    InternalError: Traceback (most recent call last):
      File "/usr/lib/python2.6/site-packages/qpid/messaging/driver.py", line 654, in write
        op.dispatch(self)
      File "/usr/lib/python2.6/site-packages/qpid/ops.py", line 84, in dispatch
        getattr(target, handler)(self, *args)
      File "/usr/lib/python2.6/site-packages/qpid/messaging/driver.py", line 870, in do_session_detached
        sst = self._sessions.pop(dtc.channel)
    KeyError: 0

Comment 1 Randy Barlow 2014-03-25 21:25:48 UTC
I think that might not be the same traceback that the bowl of eggs discussed with you. This was in the paste:

2014-03-25 15:42:31,819 pulp.server.dispatch.task:ERROR: 'NoneType' object is unsubscriptable
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/pulp/server/dispatch/task.py", line 137, in _run
    result = call(*args, **kwargs)
  File "/usr/lib/python2.6/site-packages/pulp/server/managers/consumer/applicability.py", line 137, in regenerate_applicability_for_repos
    self.regenerate_applicability(profile_hash, unit_profile['content_type'],
TypeError: 'NoneType' object is unsubscriptable
2014-03-25 15:43:30,806 pulp.plugins.yum_clone_distributor.distributor:INFO: Start publish time 1395776610.81
2014-03-25 15:45:16,145 pulp.plugins.yum_clone_distributor.distributor:INFO: Start publish time 1395776716.15
2014-03-25 15:45:27,437 pulp.server.dispatch.task:ERROR: 'NoneType' object is unsubscriptable
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/pulp/server/dispatch/task.py", line 137, in _run
    result = call(*args, **kwargs)
  File "/usr/lib/python2.6/site-packages/pulp/server/managers/consumer/applicability.py", line 137, in regenerate_applicability_for_repos
    self.regenerate_applicability(profile_hash, unit_profile['content_type'],
TypeError: 'NoneType' object is unsubscriptable

Comment 2 Randy Barlow 2014-03-25 21:27:14 UTC
The problem is that unit_profile is None in the traceback, and you just can't do None['content_type'], no matter how hard you try.

We need to fix the applicability regeneration to avoid the assumption that the unit profiles still exist when regenerating for repositories.

Comment 3 Justin Sherrill 2014-03-25 21:33:48 UTC
ack thanks randy, you are correct, had too many pastebins open :)

I'm glad you and that bowl of eggs converse occasionally

Comment 4 Sayli Karmarkar 2014-04-09 08:42:55 UTC
https://github.com/pulp/pulp/pull/890

Comment 5 Irina Gulina 2014-06-19 08:15:34 UTC
Created attachment 910283 [details]
verifiyng screenlog over RHEL6.5

Comment 6 Randy Barlow 2014-08-09 06:54:48 UTC
This has been fixed in Pulp 2.4.0-1.