Closed Bug 1512039 Opened Last year Closed 11 months ago

Stub installer support for installing AArch64 builds

Categories

(Firefox :: Installer, enhancement, P1)

ARM64
Windows
enhancement

Tracking

()

RESOLVED FIXED
Firefox 66
Tracking Status
firefox66 --- fixed

People

(Reporter: mhowell, Assigned: mhowell)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Once we have AArch64 builds available, the stub installer needs to support selecting the AArch64 platform to install on supported systems, in addition to x86 or x86-64. My guess is that we would want to select that build on every AArch64 Windows system, regardless of RAM or any of the other requirements we have for selecting x86-64.

Fortunately I don't think this requires building either installer as a native AArch64 binary, because of the x86 emulation layer that Windows provides.
See Also: → 1512699
Assignee: nobody → mhowell
Status: NEW → ASSIGNED
Priority: P2 → P1
This is blocked on having this platform actually available in Bouncer, but once that's up it should be a very small change that's needed here.
(In reply to Matt Howell (he/him) [:mhowell] from comment #1)
> This is blocked on having this platform actually available in Bouncer, but
> once that's up it should be a very small change that's needed here.

Apologies for ignorant questions, but do we have a separate bug for the Bouncer (what is Bouncer?) support, or does that bug live in a separate place, like Github?
Flags: needinfo?(mhowell)
Bouncer is the service that takes a download URL like "https://download.mozilla.org/?product=firefox-stub&os=win&lang=en-US" and redirects it to a canonical CDN path like "https://download-installer.cdn.mozilla.net/pub/firefox/releases/63.0.3/win32/en-US/Firefox Installer.exe", after running some rules to resolve things like the latest version number that should be made available. The stub installer uses that kind of download URL to make sure that it's always installing the latest available version for its channel, regardless of when the stub itself is from. The Bouncer code lives at https://github.com/mozilla-services/go-bouncer, but it's very data-driven and I'm not 100% sure what the source of its data is; hopefully it's Buildhub or something adjacent, because in that case we would get all this for free out of the existing releng machinery as soon as we have nightly builds running.
Flags: needinfo?(mhowell)
This patch also removes the last vestiges of the old architecture dropdown
structure, and removes a use of GetBinaryTypeW because it doesn't seem to
return a useful result for any ARM ISA.

We now have good Buildhub records for aarch64 (like https://buildhub.prod.mozaws.net/v1/buckets/build-hub/collections/releases/records/firefox_nightly_2019-01-07-09-30-40_66-0a1_win64-aarch64_xh) so I had hoped that maybe that would be enough to get Bouncer URL's of the form http://download.mozilla.org/?product=firefox-nightly-latest-ssl&os=win64-aarch64&lang=en-US to start working, but that one 404's still. I'm pretty clueless about Bouncer though; oremj, are you the person to ask about getting that support in, or do you know who is?

Flags: needinfo?(oremj)

Also, If the problem is just that there's something wrong with that URL and a different one would work, I can easily change any part of it.

Releng handles administration of bouncer products/oses/etc.

Flags: needinfo?(oremj) → needinfo?(rail)

Rail asked me to look at this yesterday as I'm currently on hook this cycle for product requests. I'll configure Bouncer tomorrow so it supports aarch64

Flags: needinfo?(rail)

I've manually added 4 new locations for win64-aarch64:

https://bounceradmin.mozilla.com/admin/mirror/location/51281/
https://bounceradmin.mozilla.com/admin/mirror/location/51282/
https://bounceradmin.mozilla.com/admin/mirror/location/51283/
https://bounceradmin.mozilla.com/admin/mirror/location/51284/

Verified http://download.mozilla.org/?product=firefox-nightly-latest-ssl&os=win64-aarch64&lang=en-US resolves now.

mtabara: I'm not sure if adding new nightly locations:

  1. breaks bouncer check assertions? In either our automation or Bouncer's monitoring
  2. aarch64 locations needs to be added to our newly automated bouncer version bump logic that gets actioned once a cycle?
Flags: needinfo?(mtabara)

Confirmed that the URL does indeed resolve, and also that the attached patch now installs the correct build. Thanks Jordan!

Pushed by mhowell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/47b94d26f8a5
Allow the stub installer to detect and download the AArch64 Windows build. r=agashlin
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 66

(In reply to Jordan Lund (:jlund) from comment #9)

I've manually added 4 new locations for win64-aarch64:

https://bounceradmin.mozilla.com/admin/mirror/location/51281/
https://bounceradmin.mozilla.com/admin/mirror/location/51282/
https://bounceradmin.mozilla.com/admin/mirror/location/51283/
https://bounceradmin.mozilla.com/admin/mirror/location/51284/

Verified http://download.mozilla.org/?product=firefox-nightly-latest-ssl&os=win64-aarch64&lang=en-US resolves now.

Thank you for adding these and helping unblock this last week.

mtabara: I'm not sure if adding new nightly locations:

  1. breaks bouncer check assertions? In either our automation or Bouncer's monitoring

It doesn't but it shouldn've. We have safeguards in place to ensure the payload + version coming from tree match certain regexes and are correct against what we do have in bouncer. But this usecase isn't covered in bouncerscript and it could. I'll file a separate bug for this to describe the issue and track the problem.

  1. aarch64 locations needs to be added to our newly automated bouncer version bump logic that gets actioned once a cycle?

Yes, they should. Otherwise, after the next mergeduty bump they will still serve the old value.
Since I'm doing prepping work for mergeduty anyway this week, I can piggyback on the aforemention up-to-be-filled bug.

Flags: needinfo?(mtabara)
Blocks: 1531689
You need to log in before you can comment on or make changes to this bug.