554006 - Partial update files in wrong build folder

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

Starting with today's nightly builds on m-c the partial update mar files are in the current build folder, than being in the previous day's build folder. 

With the partial mar file in the wrong folder the Updater cannot locate the file, and thus no Updates are possible for nightly testers/users.

Comment 1

[Chris Cooper [:coop] (he/him)]

It's my understanding that it doesn't matter where the partial mar actually lives, as long as the snippet points to that location.

You're right, though. Something is broken here.

Comment 3

[Jim Jeffery not reading bug-mail 1/2/11]

The update went fine for me today on m-c nightly.

Comment 4

[Chris Cooper [:coop] (he/him)]

Updates, even partial updates, are still working on m-c, but we seem to be one day behind. I was able to update to yesterday's m-c nightly on Mac from the last nightly on Sunday via a partial update

I don't see a partial offered for today yet, despite the partial existing on stage:

http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/2010-03-23-03-mozilla-central/firefox-3.7a4pre.en-US.mac.partial.20100322030612-20100323030613.mar

But AUS returns an empty update XML:

https://aus2.mozilla.org/update/3/Firefox/3.7a4pre/20100322030612/Darwin_Universal-gcc3/en-US/nightly/Darwin%2010.2.0/default/default/update.xml?force=1

This leads me to believe that the empty snippets are ending up in the wrong place. I'll spend some time today comparing where snippets are sent by the two systems (prometheus and updates-on-slave) and make sure they're identical.

Comment 5

[Chris Cooper [:coop] (he/him)]

Huh, if I repeatedly reload the above update.xml, I actually get non-empty, valid xml about once in 10 attempts.

<updates>
<update type="minor" version="3.7a4pre" extensionVersion="3.7a4pre" buildID="20100323030613">
<patch type="complete" URL="http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/03/2010-03-23-03-mozilla-central/firefox-3.7a4pre.en-US.mac.complete.mar" hashFunction="sha512" hashValue="e557b741b1d5f896f0f9c1051bef09e4c15049a28096a1405de808c45f2dced54125da39c76a49dd37935bd5fb0b959635b18854c87ec814f0f80f2c0b821c84" size="24470756"/>
<patch type="partial" URL="http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/03/2010-03-23-03-mozilla-central/firefox-3.7a4pre.en-US.mac.partial.20100322030612-20100323030613.mar" hashFunction="sha512" hashValue="7ec7cfeb14e97ca85c5d21628d87ef30208d4578be67ba070490f7d39db078fa1e6a619a178d12cd65b0e87cd8130ae3e4ea8a9a4554d9bed49baeeafe5c82e8" size="1316626"/>
</update>
</updates>

Comment 6

[vympel]

I've just downloaded the latest Nightly ... seems the problem is resolved ... just waiting for the next update attempt to confirm :-/

Comment 7

[Chris Cooper [:coop] (he/him)]

nthomas just tracked down the problem:

nthomas: hi coop|buildduty - I think I have an idea for the m-c update problem
[4:31pm] coop|buildduty: oh?
[4:32pm] nthomas: we've had a bunch of problems with NFS caching before, and I suspect that if we touch mozilla-central/%PLATFORM% after pushing the empty snippets it will pay attention properly
[4:34pm] • nthomas goes to test that with for mac
[4:34pm] coop|buildduty: that might explain the intermittent update issue
[4:34pm] coop|buildduty: i had tried touching the empty snippets themselves, but i guess that's too far down the dir chain
[4:35pm] nthomas: yeah, if you had different caching on the many webheads for aus2.m.o
[4:38pm] nthomas: took a couple of minutes, but https://aus2.mozilla.org/update/1/Firefox/3.7a4pre/2010032203/Darwin_Universal-gcc3/en-US/nightly/update.xml?force=1 is now solidly offering the 23rd build
[4:38pm] nthomas: after |touch /opt/aus2/incoming/2/Firefox/mozilla-central/Darwin_Universal-gcc3|
[4:39pm] coop|buildduty: yeah, i get the proper xml every time now
[4:40pm] nthomas: so I guess we create the new dir and push empties into it, while the old code would have also set the modification times in such a way as NFS wasn't fooled

Comment 8

[Nick Thomas [:nthomas] (UTC+12)]

I did the same for both Linux flavours and Windows, so everyone should be able to get today's build.

Comment 9

[Chris Cooper [:coop] (he/him)]

This should be fixed for good when attachment 434342 [details] [diff] [review] (or some version thereof) lands in bug 511967.