[Pulp-dev] No-Retry Behaviour on Network Errors: call for feedback and concerns

Brian Bouterse bmbouter at redhat.com
Fri May 15 17:51:05 UTC 2020

Thank you both for the input.

@jsherrill I agree. We finished the implementation planning for
https://pulp.plan.io/issues/6699 on the issue and it's now on the sprint.

@ipanova I also agree with this goal. What I'm not sure about is how to
handle it more broadly. I believe more broadly it is a missing feature of
the TaskStatus something like:  "As a user, I don't know how to interpret
the traceback because there isn't a concise error message". I put that into
this feature placeholder https://pulp.plan.io/issues/6751

The docs issue https://pulp.plan.io/issues/6624 is also on the sprint now

On Wed, May 13, 2020 at 11:20 AM Ina Panova <ipanova at redhat.com> wrote:

> I have a small suggestion.
> Besides the documentation plan I would suggest to catch the exception
> thrown on server disconnect and give to the users something more friendly
> and not have that traceback in the logs.
> --------
> Regards,
> Ina Panova
> Senior Software Engineer| Pulp| Red Hat Inc.
> "Do not go where the path may lead,
>  go instead where there is no path and leave a trail."
> On Wed, May 13, 2020 at 12:01 AM Justin Sherrill <jsherril at redhat.com>
> wrote:
>> I apparently replied instead of replied-list!  Resending:
>> I don't have known concerns (more worry about what happens as more and
>> more people use pulp3 in the real world), but i do think after reading the
>> investigation in https://pulp.plan.io/issues/6589 that the resulting
>> RFE: https://pulp.plan.io/issues/6699  is hugely important.
>> Justin
>> On 5/12/20 4:41 PM, Brian Bouterse wrote:
>> tl;dr: pulp does not retry when there are network errors or the server
>> hangs up. We are going to document this as part of this issue
>> https://pulp.plan.io/issues/6624 Please share concerns or feedback with
>> this plan before open floor on May 15th.
>> # Background
>> At open floor today we touched on how Pulp 3 downloading does not have
>> retry logic in these cases:
>> * the server hanging up the TCP connection
>> * network errors which cause TCP hangups
>> * http errors other than [429, 502, 503, 504]
>> # The Documentation Plan
>> The current plan is to document this onto docs.pulpproject.org as part
>> of this ticket https://pulp.plan.io/issues/6624. It will document:
>> * the no-retry behavior cases
>> * with the reasons why Pulp does not retry
>> * that users can retry and Pulp will effectively resume due to not having
>> to redownload content it already downloaded
>> # Feedback
>> Do you have concerns or other feedback with this plan? Is this the best
>> thing Pulp can do? If you are interested in sharing, please do before open
>> floor on Friday May 15th.
>> Thanks!
>> Brian
>> _______________________________________________
>> Pulp-dev mailing listPulp-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200515/085dad79/attachment.htm>

More information about the Pulp-dev mailing list