[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Yum, Proxy Cache Safety, Storage Backend

Les Mikesell wrote:

I'm missing something here. A cache is only going to resend what it got
the first time.  If the first user got the right thing, so will the
second.  If the first user got something wrong, don't blame the cache
for it.

There can be a problem when the cache holds on to the "bad" data for too long, serving that to other clients that ask for it later. The way things are now, a cache has a good reason _not_ to look for fresh data when the end users would like it to. In that case, some blame is on the cache, and every once in a while I have to kick squid in the butt because of that. Adjusting the tools used to update machines and to create the repos in order to help the cache make better decisions is a Good Thing.

General comments about this thread :
The default update scheme is to use multiple mirrors managed by an intelligent script. Works for a lot of people, but not everyone. I think there needs to be an assumption that some kind of administrator is going to have to opt out of that default and opt into any caching scheme. At that point the issue is how easy do we make it for the administrator to do that ? What kind of changes need to be made on the clients, and what additional infrastructure changes need to be made ?

Instant Mirror is very easy right now, at least if you have any chops as an admin. Install a rpm, twiddle the config, set up a host in DNS, distribute a repo file for the clients. My view on the intent of Mr. Togami's OP is to accept that level of ease-a-tude-inosity and make the solution less error prone. Making the opt-in easier would only be a bonus.

The way I use and configure squid for general web access caching would not make it a good cache for updates. I would rather have a separate update caching mechanism rather than try to make our squid cache do double duty. I would want more control over that update cache than whatever squid would supply automatically.

Charles Dostale

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]