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(a)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.red...
>
> 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