Bug 155946

Summary: RFE: automated downloading and caching of package updates to local disk to speed up actual user initiated updating
Product: [Fedora] Fedora Reporter: Jef Spaleta <jspaleta>
Component: PackageKitAssignee: Robin Norwood <robin.norwood>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: jonstanley, katzj, lmacken, rhughes, richard, tla, wtogami
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-18 09:01:09 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 Jef Spaleta 2005-04-25 23:00:18 UTC
Opened on warren's request.

Description of general idea:
Find a way to use idle bandwidth to cache updates locally, so that when a user
initiated update activity occurs the update can happen quickly from the locally
cached package instead of having to go hit the network on demand.

Constraints/features in no particular order of importance:
will need to be able to throttle this service based on other network activity.
You want to restrict this to using idle bandwidth if you can and prevent
disruption of normal network activity. Update caching should never ever get in
the way of downloading teletubby video clips.

You'll have to add some clock randomization to make sure all the clients in a
timezone don't all hit mirrors at the same time pulling downloads. Every hour +
random(0-30) minutes to spread out the client attempts maybe.

How about we hide this from anacron completely if possible.

Going to have to have a way to setup a predefined amount of local disk space to
use, and an algorithm to purge old cached updates as needed.

Will want to be able to distinguish the auto downloaded packages from packages
downloaded by user action. One way is to have this automated download and purge
cache area seperate from the existing yum cache or up2date spool area.
The yum and up2date cache areas are used by some users to hold fallback packages
in case installed updates are sour. You do not want an automated download/purge
service purging fallback packages that users are trying to keep as a safety net.
As updates are pulled from the auto download cache area they move into the
traditional yum/up2date cache area.  This however will require updating of
existing tools like yum and up2date to see a 2nd cache area.  

-jef"it must be written in ruby"spaleta

Comment 1 Warren Togami 2005-09-17 22:20:09 UTC
> restrict this to using idle bandwidth
This is *hard* because you don't know what the rest of the network is doing.

I think perhaps you would want the user to opt-in to background downloading like
Windows XP gives users the option.  There would also need to be a default
threshold of free disk space where it will avoid downloading stuff in order to
prevent completely filling up the disk.

> purge cache area seperate from the existing yum cache or up2date spool area.

I don't think using a separate download area for this makes any sense.

Comment 2 Jon Stanley 2008-04-23 20:29:45 UTC
Adding FutureFeature keyword to RFE's.

Comment 3 Jon Stanley 2008-05-12 19:29:04 UTC
Do we still want to do this?  I know that this comes up from time to time, and I
also think that it needs to be opt-in if we do it.

Comment 4 Bill Nottingham 2008-05-12 19:50:43 UTC
PK has an option to do something like this, IIRC. Assigning there, in any case.

Comment 5 Richard Hughes 2008-08-18 09:01:09 UTC
I don't think PK should second guess the user more than it does already. I don't want Graham (http://packagekit.org/pk-profiles.html) to have the Internet "slow down" for no reason, nor for the computer to start doing too much work when idle as ideally we should be powersaving.