Open PotentialIngenuity opened 1 year ago
So generally when users see this it has been because they're hitting the Red Hat CDN often enough that the Akamai DDoS protection starts kicking in and closing connections. Could you try reducing the download concurrency values on the sync jobs?
The problem is that the replication task doesn't currenlty provide any way to set the download_concurrency on the remotes that it creates. The default of 10 is being used everywhere.
For now you can just adjust the download_concurrency on all the remotes on the replica Pulp. The replication task will not adjust that value.
The default of 10 is being used everywhere.
Ah, that is probably it, then. In the RPM plugin we use a lower default (7 I think?) specifically to avoid triggering the CDN activity throttling.
Wait, are the replicas pointing at Pulp? If that's the case then it probably wouldn't be the CDN causing those errors to be thrown? Unless the replicated Pulp is on-demand and downloading from the CDN itself as a proxy?
that is right. it is between two pulp instances with the policy set at immediate. i was able to work around this error by reducing the download_currency value.
After some discussion at the pulpcore meeting we decided it would be better to limit the number of concurrent syncs.
The UpstreamPulp config should have an additional field called 'download_concurrency'. It should be used to set the
download_concurrency
of the remotes.Version core - 3.30.0
Describe the bug
This error appears for several of the sync jobs out of 100s that occur.
To Reproduce
Expected behavior The syncs should be successful.
Additional context