Bug 1246253

Summary:	[RFE] More robust metadata cache refresh
Product:	[Fedora] Fedora	Reporter:	Suvayu <fatkasuvayu>
Component:	dnf	Assignee:	Packaging Maintenance Team <packaging-team-maint>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	jsilhan, mluscon, packaging-team-maint, pnemade, rholy, tim.lauridsen, vmukhame
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-08-10 12:55:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Suvayu 2015-07-23 19:35:04 UTC

Description of problem:
Recently the users list saw a rather long thread with many reporting stale cache, leading to updates not showing as available. Most of them reported having to manually clean the cache to get updates.

After reading Pete's very clear explanation of how dnf uses a timer and service to keep the cache updated, I pointed out this is only as effective as the reliability of the network connection. If the connection is 50% reliable, it is quite likely the 2 hour trigger interval might end up missing the windows 50% of the time, leading to stale metadata caches rather frequently. My suggestion here is to treat a broken/bad network connection as a reboot, and schedule the next makecache attempt to some time sooner, maybe 10 mins, as it is done for reboots. Essentially the proposal is to treat network unreliability as a power cycle.

I was suggested to file and RFE, so here I am. The original thread can be found here: <http://thread.gmane.org/gmane.linux.redhat.fedora.general/459014/focus=459143>. Another related post is this one: <http://thread.gmane.org/gmane.linux.redhat.fedora.general/459014/focus=459143>

Version-Release number of selected component (if applicable):
# dnf --version
1.0.1
Installed: dnf-0:1.0.1-2.fc22.noarch at 2015-06-22 07:52
Built : Fedora Project at 2015-06-12 09:00

Installed: rpm-0:4.12.0.1-12.fc22.x86_64 at 2015-07-04 08:14
Built : Fedora Project at 2015-06-29 10:36

How reproducible:
Intermittently, see the messages on the thread linked above

Steps to Reproduce:
1. Work on a Fedora machine with an unreliable network connection
2. Hope to see the problems described in the fedora users thread
3.

Actual results:
Metadata is often very stale, leading to invisible updates

Expected results:
Metadata is always approximately 2 hours old

Additional info:

Comment 1 Honza Silhan 2015-08-10 12:55:20 UTC

You should always add `--refresh` switch to cmdline if you expect everytime the metadata updated. Any not-up-to-date repo will be reported if not successfully downloaded. I personally don't think the reshleduling the next metadata cache sooner is good solution. It would make it even more complicated and so worse maintainable. You can set lower `metadata_timer_sync`.

Comment 2 Suvayu 2015-08-10 13:26:15 UTC

I don't know if you took the time to go through the thread on the users list, but a common complaint is, adding --refresh doesn't necessarily work (see: <http://thread.gmane.org/gmane.linux.redhat.fedora.general/459014/focus=459143>).

I think rather than closing this report as WONTFIX, you should look at possibilities how to improve the situation.  I'm no dnf developer, I suggested what I thought to be a possible solution.  If the proposed approach is not acceptable, it does not mean the problem is not real.  It is still there, and users are complaining about it.  Please take the time to consider other options, instead of closing the bug.  In any case, I reported this because it was suggested by Radek Holy (IIRC).