|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:||PackageKit||Assignee:||Robin Norwood <robin.norwood>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||jonstanley, katzj, lmacken, rhughes, richard, tla, wtogami|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-08-18 09:01:09 UTC||Type:||---|
|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.