On Fri, May 27, 2016 at 11:12:39AM -0600, Kevin Fenzi wrote:
On Fri, 27 May 2016 10:35:43 +0200 Adrian Reber adrian@lisas.de wrote:
I wrote details about this in the above mentioned issue. I am not convinced it is a MirrorManager bug. It actually exactly did what it is supposed to do. The problem was that it had a newer checksum and date of a repomd.xml file which does not exist on disk anymore. It would be interesting to know if this newer repomd.xml file was at some point actually available on the filesystem. Which seems hard to find out.
Weird. I cannot think of a reason why it would have updated then un-updated.
Yes. No idea. It's just strange that metalink checksum timestamp was newer than the file and the checksum was different.
Ah, I could have a look at the netapp snapshots. But I don't seem them. Are there netapps snapshots enable for
ntap-phx2-c01-fedora01-nfs.storage.phx2.redhat.com:/fedora_ftp/fedora.redhat.com/pub
Any way to look at older versions of that directory?
There are snapshots, but currently there's 7 of them one every 4 hours, so thats only 28 hours ago. This happened longer than that right?
No. It would have been interesting to see the state at:
$ date -ud @1464076094 Tue 24 May 07:48:14 UTC 2016
That was the timestamp in the metalink.
According to the current propagation result:
https://admin.fedoraproject.org/mirrormanager/propgation
Something changed between 2016-05-24-10-28-14 and 2016-05-24-14-28-14
Ah, the propagation logs might be a good place to check.
The following is the timestamp and the value of the sha256sum of repomd.xml of /srv/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata in the database. Shortened to only include the timestamps when it changes:
2016-05-23-10-28-20 --- 4b7495d42f9661ee9f1dcab1f235bba883d619cc5185b09e191c19429aa61e9e 2016-05-24-14-28-15 --- 6c00530839492c598ba2daa41f068f9f673d39063645debb69e97a5a06dadc1a 2016-05-24-18-27-36 --- 4414edff46c7a2d9754a5b711d23227e7840031871f0049d5a546062592964f7 2016-05-26-08-28-38 --- 6c00530839492c598ba2daa41f068f9f673d39063645debb69e97a5a06dadc1a 2016-05-26-16-27-41 --- 4414edff46c7a2d9754a5b711d23227e7840031871f0049d5a546062592964f7
last propagation check in the log:
2016-05-27-16-27-28 --- 4414edff46c7a2d9754a5b711d23227e7840031871f0049d5a546062592964f7
So it seems to change sometimes back and forth. Which is strange.
Patrick, would did you do to fix the metalink errors on 2016-05-26? Did you wait for a new compose or did you touch the directory and repomd.xml file so that umdl picks up the 'changes'.
Adrian