Presto logging

Thomas M Steenholdt tmus at tmus.dk
Mon Mar 26 21:33:21 UTC 2007


Tony Nelson wrote:
> At 9:11 PM +0200 3/26/07, Thomas M Steenholdt wrote:
>> Tony Nelson wrote:
>>> At 11:26 AM +0300 3/26/07, Jonathan Dieter wrote:
>>>  ...
>>>> Also, our test server is syncing updates and extras every six hours.
>>>> Does anyone know if there's a way for the fedoraproject servers to push
>>>> updates rather than our polling?
>>> I don't think so, but you could poll just the repomd.xml metadata file
>>> pretty quickly.  If it is updated, then the repo is probably worth syncing
>>> with.  You might also check if the filelists.gz is updated as well.
>> Problem with this is, that unless special care is taken to do it this
>> way, we can't rely on the repository metadata to be updated last.
>  ...
> 
> True, but that's already broken for everybody, so this would be no
> different.  Once the metadata updates, either the other files are there or
> just about everything doesn't work.
> 
> It would be a really good idea to fix this, by splitting up the rsync into
> two lines, so that the metadata is done last.  Still, even without that,
> once the metadata changes one can assume that a repo update is happening.
> Repomd.xml is a nice small file that is always updated.

I still think implementing this in just another file will be a better 
solution. Its atomic (for lack of a better term here), in that the flag 
can always be counted on as being valid. If the flag file is not there, 
a sync is in progress, if it's there, the mirror is in synced state. The 
flag file is generated locally so there's no potential loop hole of even 
tenths of a second, like there would be the other way during the time 
when the repomd.xml is downloaded. It will not rely on data to actually 
change but reports whether a sync is in progress. It provides 
backtracking in case of staleness, errors, package corruption, etc. It 
lets you know the "age" of the mirrordata and it works without splitting 
the actual mirroring script. And all in a 30 byte file.

/Thomas





More information about the fedora-devel-list mailing list