-
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
[PR #6064/0a5ac4aa backport][3.49] [SAT-29018] Fix/corrupted RA blocks content streaming #6196
[PR #6064/0a5ac4aa backport][3.49] [SAT-29018] Fix/corrupted RA blocks content streaming #6196
Conversation
My attempt to test the upgrade process:
I assume I'm missing some steps (update deps, ...?). Will continue on monday. [0]:
|
The upgrade did work. Here were the steps:
The results
|
pulpcore/content/handler.py
Outdated
remote_artifacts = ( | ||
content_artifact.remoteartifact_set.select_related("remote") | ||
.order_by_acs() | ||
.exclude(pulp_last_updated__gte=timezone.now() - timedelta(seconds=protection_time)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I'm wondering whether it'd be better to add the timedelta to setting the "failed_at" ("pulp_last_udated" in this case) and only check against now here.
349d2a2
to
bb0b45d
Compare
c915dec
to
e4461bd
Compare
e4461bd
to
9748324
Compare
On a request for on-demand content in the content app, a corrupted Remote that contains the wrong binary (for that content) prevented other Remotes from being attempted on future requests. Now the last failed Remotes are temporarily ignored and others may be picked. Cherry-picked from: 0a5ac4a
A fix was introduced in pulpcore==3.69 which relied on a new DateTimeField called 'failed_at'. Do enable backporting that, this commits removes the migration and, as a workaround, re-purpose a compatible field (pulp_last_updated) to serve the same purpose. Co-authored-by: Matthias Dellweg <[email protected]>
9748324
to
e048db7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Thanks for all the help to get this working! |
The #6161 was not very good because it still added the field to the database.
This approaches adds a unique field to the branch which won't conflict with any future field.
It must be cleaned up later with an idempotent remove migration.
Still testing if it runs without a problem.