Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1360371 - [RFE] Provide way to restart sync
Summary: [RFE] Provide way to restart sync
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Content Management
Version: 6.2.0
Hardware: Unspecified
OS: Linux
unspecified
medium vote
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-26 14:21 UTC by James Olin Oden
Modified: 2018-09-04 19:04 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-09-04 19:04:13 UTC


Attachments (Terms of Use)

Description James Olin Oden 2016-07-26 14:21:15 UTC
Description of problem:
Presently, if there is some sort of loss in connectivity, depending on the length of time of the loss, sync's will stall.   They eventually will time out, but if there was a way to have all the sync's restarted, then that would make this situation when it occurs much more tolerable.  If this situation could be auto-detected and the sync's restarted automatically, that would be really cool.

Version-Release number of selected component (if applicable):
6.2.0

How reproducible:
N/A

Steps to Reproduce:
1. Start a sync of some version of RHEL.
2. Delete your default route
3. Wait about 10 minutes
4. Add it back.

Actual results:
Your sync will hang and eventually time out.

Expected results:
That's what I would expect, however it would be nice if it could be restarted.
Actually if you could detect a stalled link and try to reconnect that would be 
even cooler.

Comment 1 Bryan Kearney 2016-07-26 18:53:41 UTC
Moving 6.2 bugs out to sat-backlog.

Comment 3 Michael Hrivnak 2016-10-05 17:23:13 UTC
Interesting idea. My initial reaction is that this kind of feature may be best implemented as part of the client-side orchestration, where there is more knowledge about what the user might want to happen given various failure cases. There are many uncertainties about trying to determine how to handle such a retry:

- how long to wait
- how many times to retry
- which types of errors should and should not trigger some kind of retry
- how do you report the failure to the user while also retrying

Pulp itself isn't currently designed to fit this well. It would be helpful to more fully define the desired behavior before trying to scope out exactly how and where to make any changes.

Comment 4 James Olin Oden 2016-10-10 13:28:11 UTC
How long to wait:   I don't know that I care, but it should be tunable.   The smaller the timeout the the more responsive it will seem, however you'll get more false positives.   The longer the timeout the less responsive it will seem, however you can be more certain that there is indeed a problem.

How many times to retry:   3?   Again this should be tunable.

Which types of errors should and should not trigger some kind of retry:   Anything you can potentially recover should initiate a retry.   Some things you could recover from but they are out of your control (loss of connectivity upstream).   In this case an option for a manual retry is very useful.

How do you report the failure to the user while also retrying:  I can't answer that not knowing enough about satellite.   I would assume some red or yellow text showing that a retry has occurred.   Or you could have a retry count (certainly you would want that somewhere).

I'm sorry I can't be more more specific.   I haven't used Satellite enough to know what would be the best behavior.      In this case I'm just looking for a nicer user experience when syncs fail, without waiting an exorbitant amount of time to retry.

Comment 5 Michael Hrivnak 2017-01-09 19:25:21 UTC
I'm moving this over to the Content Management component for feedback on the desired user experience. If this is a feature the product wants to pursue, then once the experience is defined, we can talk about how exactly to implement it. I'm happy to participate in the planning, but this is definitely not a Pulp-only change.

Comment 6 Bryan Kearney 2018-09-04 18:54:31 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.

Comment 7 Bryan Kearney 2018-09-04 19:04:13 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.


Note You need to log in before you can comment on or make changes to this bug.