-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
repo version repair command errors with traceback #4776
Comments
reformatted traceback:
|
Can you add the error text (I think it is above the traceback in the logs)? Also it looks like the traceback was truncated. |
|
So this might be related to boto/boto3#2131 (comment) |
I was able to reproduce this only by setting the |
I was fully able to reproduce the original issue reported here. I set |
Is repair repairing the artifacts in the proper domain at all? Or is it always using the default domains storage? |
What values are being set for the domain in question? Is it possible it doesn't have all the necessary settings being set? |
Yes, the repair operates on the correct domain. There is just some code path that causes the default storage for Pulp to be evaluated. |
The domain's storage settings are correct. The domain works properly. It's only the code that does the repair that performs a |
The 'current_domain' ContextVar was not getting coppied into the thread that was running the artifact verification. The context is now explicitly copied into that thread. This patch also adds repair API tests for S3 and Azure storage backends. This patch also adds test assertions that a repository version repair task can be run in a non-default domain. fixes: pulp#4776 fixes: pulp#4806
The 'current_domain' ContextVar was not getting coppied into the thread that was running the artifact verification. The context is now explicitly copied into that thread. This patch also adds repair API tests for S3 and Azure storage backends. This patch also adds test assertions that a repository version repair task can be run in a non-default domain. fixes: pulp#4776 fixes: pulp#4806
The 'current_domain' ContextVar was not getting coppied into the thread that was running the artifact verification. The context is now explicitly copied into that thread. This patch also adds repair API tests for S3 and Azure storage backends. This patch also adds test assertions that a repository version repair task can be run in a non-default domain. fixes: pulp#4776 fixes: pulp#4806
The 'current_domain' ContextVar was not getting coppied into the thread that was running the artifact verification. The context is now explicitly copied into that thread. This patch also adds repair API tests for S3 and Azure storage backends. This patch also adds test assertions that a repository version repair task can be run in a non-default domain. fixes: #4776 fixes: #4806
The 'current_domain' ContextVar was not getting coppied into the thread that was running the artifact verification. The context is now explicitly copied into that thread. This patch also adds repair API tests for S3 and Azure storage backends. This patch also adds test assertions that a repository version repair task can be run in a non-default domain. fixes: #4776 fixes: #4806 (cherry picked from commit 95a8f47)
The 'current_domain' ContextVar was not getting coppied into the thread that was running the artifact verification. The context is now explicitly copied into that thread. This patch also adds repair API tests for S3 and Azure storage backends. This patch also adds test assertions that a repository version repair task can be run in a non-default domain. fixes: #4776 fixes: #4806 (cherry picked from commit 95a8f47)
Version
"rpm": "3.24.0",
"core": "3.41.0",
"file": "3.41.0",
Describe the bug
When running a repo repair for an rpm repo, we got a traceback on a couple of the tasks. It sorta looks its a failed download, but could be something else? If it is a failed download, is it stopping immediately?
To Reproduce
have a repo version with missing units
Repair the repo version with verify_checksums set to true
simulate a download failure (maybe?)
Get the traceback below
Expected behavior
Repair will try to redownload as much as possible before failing
Additional context
"traceback: File "/usr/local/lib/python3.8/site-packages/pulpcore/tasking/tasks.py", line 60, in _execute_task\n result = func(*args, **kwargs)\n File "/usr/local/lib/python3.8/site-packages/pulpcore/app/tasks/repository.py", line 184, in repair_version\n loop.run_until_complete(\n File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete\n return future.result()\n File "/usr/local/lib/python3.8/site-packages/pulpcore/app/tasks/repository.py", line 146, in _repair_artifacts_for_content\n valid = await loop.run_in_executor(\n File "/usr/lib64/python3.8/concurrent/futures/thread.py", line 57, in run\n result = self.fn(*self.args, **self.kwargs)\n File "/usr/local/lib/python3.8/site-packages/pulpcore/app/tasks/repository.py", line 103, in _verify_artifact\n for chunk in fp.chunks(CHUNK_SIZE):\n File "/usr/local/lib/python3.8/site-packages/django/core/files/base.py", line 55, in ...
The text was updated successfully, but these errors were encountered: