Description of problem: Synchronizing an ostree repository fails with: PLP0000: 'ascii' codec can't decode byte 0xe2 in position 28: ordinal not in range(128) This applies both to red hat atomic trees as well as various custom fedora trees. Will attach prodlog excrept. Version-Release number of selected component (if applicable): satellite-6.4.0-15.el7sat.noarch Additional info: Previously, this error was seen here https://bugzilla.redhat.com/show_bug.cgi?id=1269145
*** Bug 1645017 has been marked as a duplicate of this bug. ***
Created redmine issue https://projects.theforeman.org/issues/25713 from this bug
Upstream bug assigned to jomitsch
On a 6.4 box, I see was able to sync 'Red Hat Enterprise Linux Atomic Host Trees' without issue. Can we check this one again? I ran into issues on the first sync of 'https://kojipkgs.fedoraproject.org/atomic/27/', but a resync worked fine. ``` Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) Task pulp.server.managers.repo.sync.sync[b90e915b-126e-44a0-ab49-c26794f21251] raised unexpe cted: OverflowError('MongoDB can only handle up to 8-byte ints',) Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) Traceback (most recent call last): Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) File "/usr/lib/python2.7/site-packages/celery/app/trace.py", line 367, in trace_task Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) R = retval = fun(*args, **kwargs) Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) File "/usr/lib/python2.7/site-packages/pulp/server/async/tasks.py", line 529, in __call__ Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) return super(Task, self).__call__(*args, **kwargs) Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) File "/usr/lib/python2.7/site-packages/pulp/server/async/tasks.py", line 107, in __call__ Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) return super(PulpTask, self).__call__(*args, **kwargs) Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) File "/usr/lib/python2.7/site-packages/celery/app/trace.py", line 622, in __protected_call __ Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) return self.run(*args, **kwargs) Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) File "/usr/lib/python2.7/site-packages/pulp/server/controllers/repository.py", line 819, in sync Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) rebuild_content_unit_counts(repo_obj) Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) File "/usr/lib/python2.7/site-packages/pulp/server/controllers/repository.py", line 313, in rebuild_content_unit_counts Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) repository.save() Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) File "/usr/lib/python2.7/site-packages/mongoengine/document.py", line 367, in save Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) upsert=upsert, **write_concern) Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line 2232, in update Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) check_keys, multi, manipulate, write_concern) Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line 709, in _update Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) codec_options=self.codec_options).copy() Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) File "/usr/lib64/python2.7/site-packages/pymongo/pool.py", line 216, in command Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) self._raise_connection_failure(error) Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) File "/usr/lib64/python2.7/site-packages/pymongo/pool.py", line 343, in _raise_connection_failure Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) raise error Dec 18 15:49:04 sat-6-4-compose-rhel7 pulp: celery.app.trace:ERROR: [b90e915b] (32448-79712) OverflowError: MongoDB can only handle up to 8-byte ints ``` I think we should re-check syncing the repos on the latest 6.4 builds Versions used: [root@sat-6-4-compose-rhel7 ~]# rpm -qa | grep pulp-server pulp-server-2.16.4.1-1.el7sat.noarch [root@sat-6-4-compose-rhel7 ~]# rpm -qa | grep pulp-ostree pulp-ostree-plugins-1.3.0-1.el7sat.noarch ppython-pulp-ostree-common-1.3.0-1.el7sat.noarch [root@sat-6-4-compose-rhel7 ~]# rpm -qa | grep satellite satellite-installer-6.4.0.7-2.el7sat.noarch satellite-6.4.1-2.el7sat.noarch tfm-rubygem-foreman_theme_satellite-2.0.1.12-1.el7sat.noarch satellite-cli-6.4.1-1.el7sat.noarch satellite-common-6.4.1-1.el7sat.noarch
Hi John, I looked again on Sat 6.4.2, and I confirm that I can sync rhel atomic repos without problems. With custom fedora ostree I get the same "OverflowError: MongoDB can only handle up to 8-byte ints" error, though resync doesn't help in my case. I see that this is being handled here https://bugzilla.redhat.com/show_bug.cgi?id=1658444 so for me it's ok if we want to close this bug.
(In reply to Peter Ondrejka from comment #9) > Hi John, I looked again on Sat 6.4.2, and I confirm that I can sync rhel > atomic repos without problems. With custom fedora ostree I get the same > "OverflowError: MongoDB can only handle up to 8-byte ints" error, though > resync doesn't help in my case. I see that this is being handled here > https://bugzilla.redhat.com/show_bug.cgi?id=1658444 so for me it's ok if we > want to close this bug. This is fine with me
Closing based upon comment 8 and 9. Since the mongo error is different than the one in this report, I am going to close as notabug versus a duplicate. If there are any concerns, please do needinfo me. Thanks!