Bug 740331

Summary: Maximum metadata age should be check interval minus 30 minutes
Product: [Fedora] Fedora Reporter: Kevin Kofler <kevin>
Component: PackageKitAssignee: Richard Hughes <hughsient>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: hughsient, jonathan, rvitale, smparrish
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: 2011-09-22 10:20:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Kevin Kofler 2011-09-21 16:46:18 UTC 
(not just the check interval)

As per bug #740305:
> Plus, the max cache age probably needs to be the GUI update frequency minus
> something, or you'll end up with:
> * update check set to once per 3 days
> * GUI starts checking for updates on Monday at 12:00
> * update check completes on Monday at 12:01
> * GUI starts checking for updates on Thursday at 12:00 (exactly 3 days later)
> * cache is 2 days 23 hours 59 minutes old
> * zif sees it's not 3 days old, does nothing
> * EPIC FAIL ;-)
[…]
> Let's make it half an hour. KPK's minimum check time is hourly, and 1 hour
> minus 1 hour = 0, oops…
Comment 1 Kevin Kofler 2011-09-21 22:40:45 UTC 
The question is: Where in the food chain do we want to subtract those 30 minutes? In the PackageKit core, between the value set by the frontend and the value passed to the backend, would probably be the best place to avoid code duplication, but then the "cache-age" name for the property might be misleading…
Comment 2 Richard Hughes 2011-09-22 10:12:05 UTC 
(In reply to comment #1)
> The question is: Where in the food chain do we want to subtract those 30
> minutes? In the PackageKit core, between the value set by the frontend and the
> value passed to the backend, would probably be the best place to avoid code
> duplication, but then the "cache-age" name for the property might be
> misleading…

I think the only place it makes sense to subtract is in the PK _backend_, so that the user sends "24 hours" and this gets transformed by pk-backend-%foo.c into a cache_age of "23 hours, 30 minutes"

The backends themselves only care about cache ages, and the frontends don't want to get into the complexity (and are already doing one thing) so I think doing this in the backend makes perfect sense.

I'll work on fixing this now.

Richard.
Comment 3 Richard Hughes 2011-09-22 10:20:21 UTC 
commit 6ab9b742bc230bd3ac8a6479ea737e9557ee1843
Author: Richard Hughes <richard>
Date:   Thu Sep 22 11:19:35 2011 +0100

    Offset the cache age by 30 minutes
    
    We have to offset the cache age by 30 minutes if possible to account
    for the possible delay in running the transaction, for example:
    
    * Update check set to once per 3 days
    * GUI starts checking for updates on Monday at 12:00
    * Update check completes on Monday at 12:01
    * GUI starts checking for updates on Thursday at 12:00 (exactly 3 days later)
    * Cache is 2 days 23 hours 59 minutes old
    * Backend sees it's not 3 days old, does nothing
    
    Many thanks to Kevin Kofler for finding the problem.